Re: Small problem with BlanketPermission on the new site.
On Sat, Jan 10, 2009 at 07:06:41PM +0100, Pavel Sanda wrote: Angus Leeming wrote: We had one curmudgeonly gentleman, John Weiss, who point blank refused to licence his contribution to LyX under the GPL version 2 or later. The old flavour of this page has him down as licencing his contributions under the artistic licence. btw http://www.gnu.org/philosophy/license-list.html says Artistic License is not compatible with GPL. what does it mean wrt lyx sources themselves? do we need to ask for Artistic license 2? pavel The Artistic License is more permissive than the GPL. As most people read the GPL, if you copy-n-paste even __one__ __line__ of code from GPL source to any other file, that other file automatically becomes subjec to the GPL. As per my reading of paragraph #7 of the Artistic License, the only requirements for code-reuse are (a) your reuse does not constitute wholesale copying of the entire source with a 2-line tweak, but are only reusing chunks; and (b) you clearly label where you got the copied chunks from. The upshot is: you cannot put a GPL'd file into a codebase under the Artistic License without changing the license of the entire codebase to GPL. You can, however, put an Artistic License into a GPL'd codebase with no effect on the other files in the codebase (which remains under the GPL). -- John Weiss
Re: Small problem with BlanketPermission on the new site.
On Sat, Jan 10, 2009 at 07:06:41PM +0100, Pavel Sanda wrote: > Angus Leeming wrote: > > We had one curmudgeonly gentleman, John Weiss, who point blank refused to > > licence his contribution to LyX under the GPL version 2 or later. The old > > flavour of this page has him down as licencing his contributions under the > > artistic licence. > > btw http://www.gnu.org/philosophy/license-list.html says Artistic License > is not compatible with GPL. what does it mean wrt lyx sources themselves? > do we need to ask for Artistic license 2? > > pavel The Artistic License is more permissive than the GPL. As most people read the GPL, if you copy-n-paste even __one__ __line__ of code from GPL source to any other file, that other file automatically becomes subjec to the GPL. As per my reading of paragraph #7 of the Artistic License, the only requirements for code-reuse are (a) your "reuse" does not constitute wholesale copying of the entire source with a 2-line tweak, but are only reusing chunks; and (b) you clearly label where you got the copied chunks from. The upshot is: you cannot put a GPL'd file into a codebase under the Artistic License without changing the license of the entire codebase to GPL. You can, however, put an Artistic License into a GPL'd codebase with no effect on the other files in the codebase (which remains under the GPL). -- John Weiss
Re: The LyX licence
On Tue, Feb 22, 2005 at 12:06:02PM +, Angus Leeming wrote: Dear all, : : In light of all this, I asking whether I can have your permission to add your names to http://www.lyx.org/blanket-permission.txt: No. I have lately grown to detest FSF-Fundamentalism, and now refuse to GPL or LGPL anything of mine. But even beforehand, I preferred to release all of my code and documentation under the Artistic License. Any contributions I made to LyX (early reLyX, documentation) should therefore be considered as originally under the Artistic License. Make of that what you will. -- John Weiss
Re: The LyX licence
On Tue, Feb 22, 2005 at 12:06:02PM +, Angus Leeming wrote: > Dear all, : : > In light of all this, I asking whether I can have your permission to > add your names to http://www.lyx.org/blanket-permission.txt: No. I have lately grown to detest FSF-Fundamentalism, and now refuse to GPL or LGPL anything of mine. But even beforehand, I preferred to release all of my code and documentation under the Artistic License. Any contributions I made to LyX (early reLyX, documentation) should therefore be considered as originally under the Artistic License. Make of that what you will. -- John Weiss
Re: Pending patches for the 1.3.x tree
On Mon, Jan 24, 2005 at 01:37:38PM +, Angus Leeming wrote: Jean-Marc Lasgouttes wrote: What I was not sure about is how you handle option=='foo bar'. We don't. All hell breaks loose at this point and always has. The existing code to split a string up into an argv array is: : [snip] : Ie, we assume that ' ' marks the gap between arguments in the string. To do this properly requires a fully-formed parser of the sh language. I just ran a quick test. Any Unix shell treats --option='foo bar' as a single element of *argv[]. The single-quotes protected the space from the shell. (I tested with bash, ash, csh, tcsh, ksh, and bsh.) For Windows, however I wouldn't be surprised if whitespace chars weren't escaped. Just another one of those platform differences that'll need special handling. -- John Weiss
Re: [Patch] Refactoring PreviewLoader
On Mon, Jan 24, 2005 at 08:15:10PM +, Andreas Vox wrote: Angus Leeming [EMAIL PROTECTED] writes: namespace support = lyx::support; using std::ostream; typedef liststring SnippetList; is just baaaddd. Ah, bad for *.h, ok for *.C? Got it. The reason being that *.h files are included into other files in ways you cannot control. Conversely, those including a *.h file into their own code have no control over its contents (at least in principle). So, if you pull something into the global namespace in a header file, like using std::list; would, you force EVERY file using your header file either to use std::list at all times or to go through name-conflict-resolution-gymnatics to use the correct token called list. But the whole point of namespaces is to minimize/eliminate these sorts of gymnastics in the first place. But why is it okay for *.C? First and most obviously, source files aren't included into other source or headers. But, more importantly, a source file is a translation unit. That is, the compiler treats it (and any #include'd headers) as a self-contained entity. Any references to outside critters must be flagged as such. So, doing using std::ostream; inside of a source file only affects the contents of *that* source file, and only during the tokenization stage of compilation. (The compiler's gonna internally change any unqualified ostream tokens back into std::ostream.) At this point, we enter a discussion of stylistics and code maintenance. The bulk of one's work on a piece of code will be maintenance, not writing it initially. It's one of the old bromides of software development, actually. Therefore, good coding style dictates that you code in the future tense, using language features only in the most narrow sense. For example, you don't make all members of a class public; you only make those you absolutely need to expose public. In the future, should you need to expose one of your private member functions, it's trivial to do so witha quick cut-n-paste in your class header file. The idea behind a using clause is similar. Localize them to where you need them most, and only to there. It's not much effort to add using std::string; at the top of each new function that requires STL strings. Then, if you later find that, yes, most of the functions in this *.C file need STL strings and will never use any other kind of string, you can easily add a top-level using std::string;, no changes to exsting code necessary. Consider the converse situation, where you use the hydroge-bomb approach and start out with using std::map; at the top of your source. You merrily write away. Then one day, you need to add a new header file and some special code for a specially-optimized RDBMS-backed dictionary structure. It's also called map. So you write your new functions, add a using somespecial::map to each, and WHAMO! You get a bazillion name-conflicts at compile time. Now you not only have to remove the top-level using std::map, but you need to sift through hundreds of lines of code to find which functions actually use std::map and add in a using statement to just those functions. What a headache! There are nevertheless reasons for putting a top-level using std::foo; decl. in a file. Doing so makes a statement: Don't even THINK of using another type of fooXYZ with this code! Putting in a toplevel using std::ostream; tells future authors that no one, no one at all, should even try to use anything but the STL ostream with this code... put it in another source file and link the two together instead! Does that help at all, Andreas? -- John Weiss
Let's All Attack John...
On Tue, Jan 25, 2005 at 09:16:38AM +0100, Asger Ottar Alstrup wrote: John Weiss wrote: [A great opportunity to have a little flame-fest.] You're the one attacking me out-of-hand. Not FUD. Reality. [Long story about something irrelevant.] Took them YEARS to get it to that state. Sad for them. I have a working LyX. It took a week of work while Elias was sleeping. All you are saying is FUD, and the proof is in the code. You can repeat the same stories ten times, but they will still be FUD. So, in other words, my professional experiences don't count for shit as far as you're concerned, you'd just rather insult highly-intelligent former-coworkers of mine for whom I have great respect and who did Windows/Unix-platform-independence some 10 years ago, before there was a Cygwin, before there was a QT, and before there was a Boost. Then, to top off your insult-fest, you have the gall to claim that I'm the one doing the flaming?!? You could've asked me *what* I was basing my claims on instead of name-calling. You could've found out that I've been comparing Boost's way of doing platform-indep. to what I saw at my former employer. You could've just said, Warnings acknowledged, but John, I don't think it'll be that bad as most of the heavy-lifting's been done in QT and/or Boost. You could've bothered to find out that I'm not at all against a Windows version of LyX, and that after certain legal issues have been cleared up with my present (new) employer, I would've been interested in working on a plaform-indep. abstraction. In short, you could've chosen any number of more civil forms of communication. You didn't. Well, I'm calling you on it, Asger: You instead chose to selectively edit so you could publicly insult and humiliate me. I thought I'd earned a bit of respect from you by now; you certainly had mine. Now... now I'm not even sure I want to be bothered with LyX. I've been through 3 years of job-hell. I don't need this added stress. -- John Weiss
Re: lyxbreaker???
On Tue, Jan 25, 2005 at 02:38:54PM +, Angus Leeming wrote: Which means that it's dead easy to set a break point in gdb. Any entry into lyxbreaker is automatically invalid, so stop there and have a look at the execution path to that point. Try it yourself: gdb ./lyx (gdb) break lyxbreaker Breakpoint 1 at 0x120132a34: file ostream, line 193. (gdb) run Ok, time for another language lesson: While, break means set a breakpoint to most of us comp.sci. types, in common English, it can mean smash with a hammer into little inoperable bits. When you add the -er suffix, however, only the latter meaning remains. That is, a Zbreaker would be someone who rips apart Z so that it's now broken. Incidentally, I'm gonna take a guess that the break in a debugger is related to circuit breaker, the thing in your electric panel that severs an electrical circuit pulling too many amps. In short: calling a function lyxbreaker is a Bad Idea, as it implies that this function somehow damages LyX. Better to call it lyxstopper or lyxbreakpt, the latter being far more descriptive if its purpose. -- John Weiss
Re: Nasty qt-3.3.3 bug
On Sun, Jan 23, 2005 at 09:57:26PM +0200, Martin Vermeer wrote: (This also reminded me how VERY VERY VERY unhappy I am about Math not having its own top-level menu entry anymore. It is such a separate and special part of both LyX and LaTeX, that this old practice was more than justified. IMHO of course.) Seconded. -- John Weiss
Questioning Why I Bother.
On Tue, Jan 25, 2005 at 09:30:45AM +, Angus Leeming wrote: John Weiss wrote: On Fri, Jan 21, 2005 at 09:57:48PM +, Angus Leeming wrote: Cygwin's POSIX emulation layer avoids the need for the various workarounds required when using other compilers under MS-Windows. See! See! I *am* speaking from real experience! I'm not just some idiot talking out his ass like Asger says I am! John, with all due respect, you're starting to rant. Umm... Gee, maybe that's because, oh, I dunno, I'M FEELING PERSONALLY ATTACKED HERE?! I thought that maybe, just maybe, after being a contributor in some form or other for 8+ years now I've deluded myself into thinking I had your collective respect? I foolishly thought that, at least here, my acumulated technical experience from the workplace would have *some* use, that it counted for something at least here. Clearly, I was wrong. I've been through 4 years of career-destroying Job Hell. My chances of flexing ... well, really, *anything* of my technical skills, let alone doing any C++ programming ... on the job in the next 2 years are slim to none. I've been forced into signing an NDA that would lay claim to anything creative I do. So, I've been holding off even looking at LyX code to protect it until I have my concerns with that NDA legally dealt with. (It's taken me nearly 3 months to get it resolved.) And what do I get for it? Personally attacked and insulted. Gee, thanks. -- John Weiss
Re: LyX on Windows
On Mon, Jan 24, 2005 at 10:01:09AM +0100, Lars Gullik Bjønnes wrote: Sure it is nice to compile on more than one compiler... but if the result is muddier code then I am not sure about the gain. (and not that I have not said that this is the case, just a thing to watch out for. And avoiding muddy code in a Unix-Windows-crossplatform program will require a bit of work (in which I include careful planning). Which was the whole point of those cautioning posts of mine. -- John Weiss
Re: [rework docs] default figure placement inside float
On Wed, Jan 26, 2005 at 02:24:05AM +0100, Uwe Stöhr wrote: Martin Vermeer wrote: What he means is that the figure is formally embedded in a paragraph inside the float, which is formatted justified (out of alternatives left, right, justified and centred). This means the picture will align with the left edge, being just one huge character in the paragraph. Yes, that was what I meant. Yeah, I kinda figured that, Uwe. What I'm wondering is: are figure floats automatically left-justified? (That's what I meant by LaTeX-ism.) I *vaguely* recall having to do some sorta preamble-hack to get my 100+ pages of figures for my thesis to appear centered on the page at the size I wanted. But it's been over 6 years since then, and my memory's failing. And, agreed, would be nice if the justification of an figure float were tunable. (How easy it would be... I'd have to dig out my dissertation and see if I'm even on the right track here, or if my memory's flakey.) -- John Weiss
Re: Pending patches for the 1.3.x tree
On Mon, Jan 24, 2005 at 01:37:38PM +, Angus Leeming wrote: > Jean-Marc Lasgouttes wrote: > > What I was not sure about is how you handle option=='foo bar'. > > We don't. All hell breaks loose at this point and always has. The existing > code to split a string up into an argv array is: : [snip] : > Ie, we assume that ' ' marks the gap between arguments in the string. To do > this properly requires a fully-formed parser of the sh language. I just ran a quick test. Any Unix shell treats "--option='foo bar'" as a single element of "*argv[]". The single-quotes protected the space from the shell. (I tested with bash, ash, csh, tcsh, ksh, and bsh.) For Windows, however I wouldn't be surprised if whitespace chars weren't escaped. Just another one of those platform differences that'll need special handling. -- John Weiss
Re: [Patch] Refactoring PreviewLoader
On Mon, Jan 24, 2005 at 08:15:10PM +, Andreas Vox wrote: > > Angus Leeming <[EMAIL PROTECTED]> writes: > > namespace support = lyx::support; > > using std::ostream; > > typedef list SnippetList; > > > > is just baaaddd. > > Ah, bad for *.h, ok for *.C? > Got it. The reason being that *.h files are included into other files in ways you cannot control. Conversely, those including a *.h file into their own code have no control over its contents (at least in principle). So, if you pull something into the global namespace in a header file, like "using std::list;" would, you force EVERY file using your header file either to use "std::list" at all times or to go through name-conflict-resolution-gymnatics to use the correct token called "list". But the whole point of namespaces is to minimize/eliminate these sorts of gymnastics in the first place. But why is it okay for *.C? First and most obviously, source files aren't included into other source or headers. But, more importantly, a source file is a "translation unit". That is, the compiler treats it (and any #include'd headers) as a self-contained entity. Any references to outside critters must be flagged as such. So, doing "using std::ostream;" inside of a source file only affects the contents of *that* source file, and only during the tokenization stage of compilation. (The compiler's gonna internally change any unqualified "ostream" tokens back into "std::ostream".) At this point, we enter a discussion of stylistics and code maintenance. The bulk of one's work on a piece of code will be maintenance, not writing it initially. It's one of the old bromides of software development, actually. Therefore, "good coding style" dictates that you "code in the future tense," using language features only in the most narrow sense. For example, you don't make all members of a class "public"; you only make those you absolutely need to expose public. In the future, should you need to expose one of your private member functions, it's trivial to do so witha quick cut-n-paste in your class header file. The idea behind a "using" clause is similar. Localize them to where you need them most, and only to there. It's not much effort to add "using std::string;" at the top of each new function that requires STL strings. Then, if you later find that, yes, most of the functions in this *.C file need STL strings and will never use any other kind of string, you can easily add a top-level "using std::string;", no changes to exsting code necessary. Consider the converse situation, where you use the hydroge-bomb approach and start out with "using std::map"; at the top of your source. You merrily write away. Then one day, you need to add a new header file and some special code for a specially-optimized RDBMS-backed dictionary structure. It's also called "map". So you write your new functions, add a "using somespecial::map" to each, and WHAMO! You get a bazillion name-conflicts at compile time. Now you not only have to remove the top-level "using std::map", but you need to sift through hundreds of lines of code to find which functions actually use std::map and add in a "using" statement to just those functions. What a headache! There are nevertheless reasons for putting a top-level "using std::foo;" decl. in a file. Doing so makes a statement: Don't even THINK of using another type of "fooXYZ" with this code! Putting in a toplevel "using std::ostream;" tells future authors that no one, no one at all, should even try to use anything but the STL ostream with this code... put it in another source file and link the two together instead! Does that help at all, Andreas? -- John Weiss
Let's All Attack John...
On Tue, Jan 25, 2005 at 09:16:38AM +0100, Asger Ottar Alstrup wrote: > John Weiss wrote: > [A great opportunity to have a little flame-fest.] You're the one attacking me out-of-hand. > >Not FUD. Reality. [Long story about something irrelevant.] > > Took them YEARS to get it to that state. > > Sad for them. I have a working LyX. It took a week of work while Elias > was sleeping. All you are saying is FUD, and the proof is in the code. > > You can repeat the same stories ten times, but they will still be FUD. So, in other words, my professional experiences don't count for shit as far as you're concerned, you'd just rather insult highly-intelligent former-coworkers of mine for whom I have great respect and who did Windows/Unix-platform-independence some 10 years ago, before there was a Cygwin, before there was a QT, and before there was a Boost. Then, to top off your insult-fest, you have the gall to claim that I'm the one doing the flaming?!? You could've asked me *what* I was basing my claims on instead of name-calling. You could've found out that I've been comparing Boost's way of doing platform-indep. to what I saw at my former employer. You could've just said, "Warnings acknowledged, but John, I don't think it'll be that bad as most of the heavy-lifting's been done in QT and/or Boost." You could've bothered to find out that I'm not at all against a Windows version of LyX, and that after certain legal issues have been cleared up with my present (new) employer, I would've been interested in working on a plaform-indep. abstraction. In short, you could've chosen any number of more civil forms of communication. You didn't. Well, I'm calling you on it, Asger: You instead chose to selectively edit so you could publicly insult and humiliate me. I thought I'd earned a bit of respect from you by now; you certainly had mine. Now... now I'm not even sure I want to be bothered with LyX. I've been through 3 years of job-hell. I don't need this added stress. -- John Weiss
Re: lyxbreaker???
On Tue, Jan 25, 2005 at 02:38:54PM +, Angus Leeming wrote: > > Which means that it's dead easy to set a break point in gdb. Any entry > into lyxbreaker is automatically invalid, so stop there and have a look at > the execution path to that point. > > Try it yourself: > gdb ./lyx > (gdb) break lyxbreaker > Breakpoint 1 at 0x120132a34: file ostream, line 193. > (gdb) run Ok, time for another language lesson: While, "break" means set a breakpoint to most of us comp.sci. types, in common English, it can mean "smash with a hammer into little inoperable bits". When you add the "-er" suffix, however, only the latter meaning remains. That is, a "Zbreaker" would be someone who rips apart "Z" so that it's now broken. Incidentally, I'm gonna take a guess that the "break" in a debugger is related to "circuit breaker", the thing in your electric panel that severs an electrical circuit pulling too many amps. In short: calling a function "lyxbreaker" is a Bad Idea, as it implies that this function somehow damages LyX. Better to call it "lyxstopper" or "lyxbreakpt", the latter being far more descriptive if its purpose. -- John Weiss
Re: Nasty qt-3.3.3 bug
On Sun, Jan 23, 2005 at 09:57:26PM +0200, Martin Vermeer wrote: > > (This also reminded me how VERY VERY VERY unhappy I am about Math not > having its own top-level menu entry anymore. It is such a separate and > special part of both LyX and LaTeX, that this old practice was more than > justified. IMHO of course.) Seconded. -- John Weiss
Questioning Why I Bother.
On Tue, Jan 25, 2005 at 09:30:45AM +, Angus Leeming wrote: > John Weiss wrote: > > > On Fri, Jan 21, 2005 at 09:57:48PM +, Angus Leeming wrote: > >> Cygwin's POSIX emulation layer avoids > >> the need for the various workarounds required when using other > >> compilers under MS-Windows. > > > > See! See! I *am* speaking from real experience! I'm not just some > > idiot talking out his ass like Asger says I am! > > John, with all due respect, you're starting to rant. Umm... Gee, maybe that's because, oh, I dunno, I'M FEELING PERSONALLY ATTACKED HERE?! I thought that maybe, just maybe, after being a contributor in some form or other for 8+ years now I've deluded myself into thinking I had your collective respect? I foolishly thought that, at least here, my acumulated technical experience from the workplace would have *some* use, that it counted for something at least here. Clearly, I was wrong. I've been through 4 years of career-destroying Job Hell. My chances of flexing ... well, really, *anything* of my technical skills, let alone doing any C++ programming ... on the job in the next 2 years are slim to none. I've been forced into signing an NDA that would lay claim to anything creative I do. So, I've been holding off even looking at LyX code to protect it until I have my concerns with that NDA legally dealt with. (It's taken me nearly 3 months to get it resolved.) And what do I get for it? Personally attacked and insulted. Gee, thanks. -- John Weiss
Re: LyX on Windows
On Mon, Jan 24, 2005 at 10:01:09AM +0100, Lars Gullik Bjønnes wrote: > > Sure it is nice to compile on more than one compiler... but if the > result is muddier code then I am not sure about the gain. (and not > that I have not said that this is the case, just a thing to watch out > for. And avoiding muddy code in a Unix-Windows-crossplatform program will require a bit of work (in which I include careful planning). Which was the whole point of those cautioning posts of mine. -- John Weiss
Re: [rework docs] default figure placement inside float
On Wed, Jan 26, 2005 at 02:24:05AM +0100, Uwe Stöhr wrote: > Martin Vermeer wrote: > > >What he means is that the figure is formally embedded in a paragraph > >inside the float, which is formatted "justified" (out of alternatives > >left, right, justified and centred). This means the picture will align > >with the left edge, being just one huge "character" in the paragraph. > > Yes, that was what I meant. Yeah, I kinda figured that, Uwe. What I'm wondering is: are figure floats automatically left-justified? (That's what I meant by "LaTeX-ism".) I *vaguely* recall having to do some sorta preamble-hack to get my 100+ pages of figures for my thesis to appear centered on the page at the size I wanted. But it's been over 6 years since then, and my memory's failing. And, agreed, would be nice if the justification of an figure float were tunable. (How easy it would be... I'd have to dig out my dissertation and see if I'm even on the right track here, or if my memory's flakey.) -- John Weiss
Re: LyX on Windows
On Sat, Jan 22, 2005 at 03:30:44PM +0100, Asger Ottar Alstrup wrote: John Weiss wrote: Doing true full-Windows support in an inherently-unix program is a very thorny, messy situation. Have a look at the patch and then give your comments rather than this FUD. Not FUD. Reality. Be fair, Asger, and include the other sentences in the paragraph. Specifically, the one about one place where I used to work. They had the *best* platform-independence-layer I've seen *anywhere* since. That layer handled, seamlessly, 3 Unix flavors and Windows NT. Took them YEARS to get it to that state. Every time we needed a new OS-level library call, it took the guy who maintained the platform-independence-layer, a really stellar, bright guy with a CompSci PhD, *at* *least* 2 weeks to get a clean, forward-maintainable implementation in place. I know; I threw in a quick-kludge for one piece of code I was working on, and didn't replace the kludge with the corresponding implementation from the P.I.-layer until months later. So, don't you *dare* accuse me of FUD; I speak from direct experience. Besides, right now (besides ad-hominem attacks) you're most likely picking the low-hanging fruit so to speak. It's what any good software developer would do. However, I fear, based on your dismissive reaction, that you're extrapolating your current focus to all cases. The Unix/Windows platform-indep.-layer problem isn't intractable. However, it's far from non-trivial. Eventually, Asger, you *will* hit the thornier stuff, and the pitched screaming between you and Lars will commence. Asger Wrote: Further out, I'd even like to kick out LaTeX, and put some other backend in instead to reduce the footprint. Then Asger Wrote: To clarify, I would never drop LaTeX support, Language Lesson: In most dialects of English, those two statements are mutually exclusive. The only dialect where it's not is that spoken in Washington D.C. -- John Weiss
Re: lyx-devel src/: Bidi.h BufferView.h BufferView_pimpl.h Cut ...
On Thu, Jan 20, 2005 at 09:59:20AM +0100, Lars Gullik Bjønnes wrote: Asger Ottar Alstrup [EMAIL PROTECTED] writes: | If any of you twits had bothered to look, you would see that the | second patch actually changed the definitions, rather than the forward | declarations. :-) So its you that are the joy-killer now. Decidedly mean, IMNSHO. -- John Weiss
Re: Signal handling on Windows
On Wed, Jan 19, 2005 at 10:12:25AM +, Angus Leeming wrote: Angus Leeming wrote: I've been trying out the signal handler on Windows. Executive summary: SIGFPE and SIGSEGV are handled properly. The other signals are essentially useless on Windows machines. However, the Windows task manager will apparently post a WM_CLOSE message to LyX before wacking it with a TerminateProcess. Thus, it would be intelligent to add a handler for this message instead of the useless SIGTERM hander. ...nd we hit the first Dragon of platform-independence. ;) ...and the good news is that Qt provides a handle to do this and that we use it already. ...which brings me back to my earlier statement: we need to go through a p.i.-layer, be it our own, or someone else's. ;) -- John Weiss
Re: MSVC milestone 1: Everything compiles, 24 linker errors to milestone 2
On Thu, Jan 20, 2005 at 01:44:58PM +0100, Asger Ottar Alstrup wrote: Hi, The result of today's work is this: Everything compiles with the attached patch and new files placed as usual. I did a bunch of gross ^^^6 hacks here and there, but there are some good bits in there, which Angus might steal. Not surprising. This is what I mean by adding platform-indep-Windows-support to an inherently Unix app. is thorny: you have ugly hacks to start, with cleanup (possibly) requiring some deep thought. Have I *finally* made myself clear, Asger? Have I overexplained my past experiences sufficiently enough that you won't jump all over me? -- John Weiss
Re: LyX on Windows
On Sat, Jan 22, 2005 at 09:50:51AM +0100, Andre Poenitz wrote: On Tue, Jan 18, 2005 at 07:36:36AM -0500, John Weiss wrote: On Mon, Jan 17, 2005 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: I feel we are beginning on a slippery slope now... ok to support windows if only minimal changes are needed... but now we see more and more changes needed to support this. I am not sure that I am really happy about this progress Nor should you be. Doing true full-Windows support in an inherently-unix program is a very thorny, messy situation. I don't see any particular strong reason to dislike either. It's not a matter of dislike. It's a warning: There Be Dragons Here. And, it's a warning from someone who's spoken with the knights who went into that cave before, long ago. And who has a scorchmark or two of his own. BTW: Thanks, Andre, for reminding me *why* I responded in the first place, a response rather unfairly dismissed by Asger with an ad-hominem attack. The arguing *has* already started. Guys, guys: There's a reason why a Proxy-API like Cygwin exists. (By Proxy, I mean the design-patterns defn. of the term.) Because, eventually, any program that supports both Windows and Unix will have to make some of its calls through such a platform-independent Proxy-API. Whether that Proxy-API is someone else's do-everything-for-everyone solution (like Cygwin), or whether you implement it yourself just for your program is immaterial. The exercise of writing those Proxy classes can be a lot of fun. Nevertheless, someone will need to do it and it will take effort. (IIRC, the guy I keep mentioning from where I used to work had also done some platform-independence-layer-stuff for VAX--Unix, and it wasn't any easier. Seems to be the nature of the beast.) P.S.: I'm not saying all of this to be discouraging. Asger, by all means, *do* write a good pi-layer for LyX. You're certainly capable of it. I'm just saying that you're heading into the Dragons' Cave with nowhere near as much armor as those who trod in before you wore. :) -- John Weiss
Re: [rework docs] default figure placement inside float
On Thu, Jan 20, 2005 at 01:09:21AM +0100, Uwe Stöhr wrote: Hello LyXers, since LyX 1.2.x a figure is by default inserted into a float as a justified paragraph instead of a centered one. This behaviour is very annoying for many users (me too) because one have to use the menu Layout - Paragraph - Alignment for nearly every float. (Ca. 90% of the figure floats contain only one image and these are normally centered.) Uwe, this could be one of those LaTeX-isms that's been lingering in LyX for a while. If you could be more specific vis-a-vis what you mean by justified paragraph, I might be able to explain what's going on. (Maybe not, though, as I'm doing this from a laptop on a train.) -- John Weiss
Re: MSVC milestone 1: Everything compiles, 24 linker errors to milestone 2
On Fri, Jan 21, 2005 at 09:57:48PM +, Angus Leeming wrote: Cygwin's POSIX emulation layer avoids the need for the various workarounds required when using other compilers under MS-Windows. See! See! I *am* speaking from real experience! I'm not just some idiot talking out his ass like Asger says I am! -- John Weiss
Re: LyX on Windows
On Sat, Jan 22, 2005 at 03:30:44PM +0100, Asger Ottar Alstrup wrote: > John Weiss wrote: > >Doing true full-Windows support in an inherently-unix program is a > >very thorny, messy situation. > > Have a look at the patch and then give your comments rather than this FUD. Not FUD. Reality. Be fair, Asger, and include the other sentences in the paragraph. Specifically, the one about one place where I used to work. They had the *best* platform-independence-layer I've seen *anywhere* since. That layer handled, seamlessly, 3 Unix flavors and Windows NT. Took them YEARS to get it to that state. Every time we needed a new OS-level library call, it took the guy who maintained the platform-independence-layer, a really stellar, bright guy with a CompSci PhD, *at* *least* 2 weeks to get a clean, forward-maintainable implementation in place. I know; I threw in a quick-kludge for one piece of code I was working on, and didn't replace the kludge with the corresponding implementation from the P.I.-layer until months later. So, don't you *dare* accuse me of FUD; I speak from direct experience. Besides, right now (besides ad-hominem attacks) you're most likely "picking the low-hanging fruit" so to speak. It's what any good software developer would do. However, I fear, based on your dismissive reaction, that you're extrapolating your current focus to all cases. The Unix/Windows platform-indep.-layer problem isn't intractable. However, it's far from non-trivial. Eventually, Asger, you *will* hit the thornier stuff, and the pitched screaming between you and Lars will commence. > Asger Wrote: > > > Further out, I'd even like to kick out LaTeX, and put some > > > other backend in instead to reduce the footprint. > > Then Asger Wrote: > > To clarify, I would never drop LaTeX support, Language Lesson: In most dialects of English, those two statements are mutually exclusive. The only dialect where it's not is that spoken in Washington D.C. -- John Weiss
Re: lyx-devel src/: Bidi.h BufferView.h BufferView_pimpl.h Cut ...
On Thu, Jan 20, 2005 at 09:59:20AM +0100, Lars Gullik Bjønnes wrote: > Asger Ottar Alstrup <[EMAIL PROTECTED]> writes: > > | If any of you twits had bothered to look, you would see that the > | second patch actually changed the definitions, rather than the forward > | declarations. > > :-) > > So its you that are the joy-killer now. Decidedly mean, IMNSHO. -- John Weiss
Re: Signal handling on Windows
On Wed, Jan 19, 2005 at 10:12:25AM +, Angus Leeming wrote: > Angus Leeming wrote: > > > I've been trying out the signal handler on Windows. Executive summary: > > SIGFPE and SIGSEGV are handled properly. The other signals are > > essentially useless on Windows machines. However, the Windows task > > manager will apparently post a WM_CLOSE message to LyX before wacking it > > with a TerminateProcess. Thus, it would be intelligent to add a handler > > for this message instead of the useless SIGTERM hander. ...nd we hit the first Dragon of platform-independence. ;) > ...and the good news is that Qt provides a handle to do this and that we > use it already. ...which brings me back to my earlier statement: we need to go through a p.i.-layer, be it our own, or someone else's. ;) -- John Weiss
Re: MSVC milestone 1: Everything compiles, 24 linker errors to milestone 2
On Thu, Jan 20, 2005 at 01:44:58PM +0100, Asger Ottar Alstrup wrote: > Hi, > > The result of today's work is this: Everything compiles with the > attached patch and new files placed as usual. I did a bunch of gross ^^^6 > hacks here and there, but there are some good bits in there, which Angus > might steal. Not surprising. This is what I mean by "adding platform-indep-Windows-support to an inherently Unix app. is thorny": you have ugly hacks to start, with cleanup (possibly) requiring some deep thought. Have I *finally* made myself clear, Asger? Have I overexplained my past experiences sufficiently enough that you won't jump all over me? -- John Weiss
Re: LyX on Windows
On Sat, Jan 22, 2005 at 09:50:51AM +0100, Andre Poenitz wrote: > On Tue, Jan 18, 2005 at 07:36:36AM -0500, John Weiss wrote: > > On Mon, Jan 17, 2005 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: > > > > > > I feel we are beginning on a slippery slope now... ok to support > > > windows if only minimal changes are needed... but now we see more and > > > more changes needed to support this. > > > > > > I am not sure that I am really happy about this "progress" > > > > Nor should you be. > > > > Doing true full-Windows support in an inherently-unix program is a > > very thorny, messy situation. > > > I don't see any particular strong reason to dislike either. It's not a matter of dislike. It's a warning: There Be Dragons Here. And, it's a warning from someone who's spoken with the knights who went into that cave before, long ago. And who has a scorchmark or two of his own. BTW: Thanks, Andre, for reminding me *why* I responded in the first place, a response rather unfairly dismissed by Asger with an ad-hominem attack. The arguing *has* already started. Guys, guys: There's a reason why a Proxy-API like Cygwin exists. (By "Proxy", I mean the design-patterns defn. of the term.) Because, eventually, any program that supports both Windows and Unix will have to make some of its calls through such a platform-independent Proxy-API. Whether that Proxy-API is someone else's do-everything-for-everyone solution (like Cygwin), or whether you implement it yourself just for your program is immaterial. The exercise of writing those Proxy classes can be a lot of fun. Nevertheless, someone will need to do it and it will take effort. (IIRC, the guy I keep mentioning from where I used to work had also done some platform-independence-layer-stuff for VAX<-->Unix, and it wasn't any easier. Seems to be the nature of the beast.) P.S.: I'm not saying all of this to be discouraging. Asger, by all means, *do* write a good pi-layer for LyX. You're certainly capable of it. I'm just saying that you're heading into the Dragons' Cave with nowhere near as much armor as those who trod in before you wore. :) -- John Weiss
Re: [rework docs] default figure placement inside float
On Thu, Jan 20, 2005 at 01:09:21AM +0100, Uwe Stöhr wrote: > Hello LyXers, > > since LyX 1.2.x a figure is by default inserted into a float as a > justified paragraph instead of a centered one. This behaviour is very > annoying for many users (me too) because one have to use the menu Layout > -> Paragraph -> Alignment for nearly every float. (Ca. 90% of the figure > floats contain only one image and these are normally centered.) Uwe, this could be one of those LaTeX-isms that's been lingering in LyX for a while. If you could be more specific vis-a-vis what you mean by "justified paragraph", I might be able to explain what's going on. (Maybe not, though, as I'm doing this from a laptop on a train.) -- John Weiss
Re: MSVC milestone 1: Everything compiles, 24 linker errors to milestone 2
On Fri, Jan 21, 2005 at 09:57:48PM +, Angus Leeming wrote: > Cygwin's POSIX emulation layer avoids > the need for the various workarounds required when using other > compilers under MS-Windows. See! See! I *am* speaking from real experience! I'm not just some idiot talking out his ass like Asger says I am! -- John Weiss
Re: [rework docs] more questions
On Sun, Jan 16, 2005 at 07:42:22PM +0100, Uwe Stöhr wrote: Thanks for the explanation. The defskip feature might be useful, but only with a better GUI-implementation. The user isn't informed where he can adjust the value and it is unintuitive that he has to it in completely differend dialog window. I'll explain defskip in the docs but the its implementation should definitivly be changed for the next LyX version. Why? It's been part of LaTeX for, oh, nearly 2 decades now... And just because it doesn't show on the GUI doesn't make it invalid. Long Live WYSIWYM! So, it has its place. Needed to avoid too much ERT, which is such an anathema these days. grumble Since most users won't touch it most of the time, that makes it a *perfect* candidate for the Extended.lyx manual. [See? See? There *was* a method to my original design madness! ;)] -- John Weiss
Re: LyX on Windows
On Mon, Jan 17, 2005 at 11:55:56AM +, Angus Leeming wrote: Asger Ottar Alstrup wrote: That is something to address then for a native Windows port to work out. I'd like to produce a native LyX binary with as few unix dependencies as possible. Further out, I'd even like to kick out LaTeX, and put some other backend in instead to reduce the footprint. Okay, now that's just plain weird. (La)TeX has been producing decent output for 2 decades. It *still* beats the undies off of any Micro$oft product. Its only problem is that its power comes at a price. LyX drops that price greatly. Always has, too. I've been looking at this whole LyX-on-Windows thingy as a way of facilitating greater ease-of-use of (La)TeX on Windows, not as a way of bypassing it. Why reinvent the wheel?!? Or to paraphrase Jamie Zawinsky: That's like banging two rocks together and being proud that you've rederived fire from first principles. It's a solved problem, and not worth revisiting. -- John Weiss
Re: [wishlist] server-client-architecture for LyX
On Sat, Jan 15, 2005 at 11:45:27AM +0100, Andre Poenitz wrote: On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote: I didn't know LyX was that clean internally. For most other apps that would be close to a rewrite of the core parts. Guess what we did in the 1.4 cycle. Ain't it great to see the payoff? :) -- John Weiss
Re: LyX on Windows
On Mon, Jan 17, 2005 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: I feel we are beginning on a slippery slope now... ok to support windows if only minimal changes are needed... but now we see more and more changes needed to support this. I am not sure that I am really happy about this progress Nor should you be. Doing true full-Windows support in an inherently-unix program is a very thorny, messy situation. You start running into the need to create a totally indenpendent platform-layer, doing the equivalent of standard Posix functions with pure Win-libs often requires odd gymnastics... I could go on. Suffice it to say that it's enough to keep a CompSci PhD fully employed at one place I used to work. Best to keep things simple for now, as Lars says. -- John Weiss
Re: [rework docs] more questions
On Sun, Jan 16, 2005 at 07:42:22PM +0100, Uwe Stöhr wrote: > > Thanks for the explanation. The defskip feature might be useful, but > only with a better GUI-implementation. The user isn't informed where he > can adjust the value and it is unintuitive that he has to it in > completely differend dialog window. > > I'll explain defskip in the docs but the its implementation should > definitivly be changed for the next LyX version. Why? It's been part of LaTeX for, oh, nearly 2 decades now... And just because it doesn't show on the GUI doesn't make it invalid. Long Live WYSIWYM! So, it has its place. Needed to avoid too much ERT, which is such an anathema these days.Since most users won't touch it most of the time, that makes it a *perfect* candidate for the Extended.lyx manual. [See? See? There *was* a method to my original design madness! ;)] -- John Weiss
Re: LyX on Windows
On Mon, Jan 17, 2005 at 11:55:56AM +, Angus Leeming wrote: > Asger Ottar Alstrup wrote: > > That is something to address then for a native Windows port to work out. > > I'd like to produce a native LyX binary with as few unix dependencies as > > possible. > > > > Further out, I'd even like to kick out LaTeX, and put some > > other backend in instead to reduce the footprint. Okay, now that's just plain weird. (La)TeX has been producing decent output for 2 decades. It *still* beats the undies off of any Micro$oft product. Its only problem is that its power comes at a price. LyX drops that price greatly. Always has, too. I've been looking at this whole LyX-on-Windows thingy as a way of facilitating greater ease-of-use of (La)TeX on Windows, not as a way of bypassing it. Why reinvent the wheel?!? Or to paraphrase Jamie Zawinsky: That's like banging two rocks together and being proud that you've rederived fire from first principles. It's a solved problem, and not worth revisiting. -- John Weiss
Re: [wishlist] server-client-architecture for LyX
On Sat, Jan 15, 2005 at 11:45:27AM +0100, Andre Poenitz wrote: > On Thu, Jan 13, 2005 at 03:28:31PM -0500, Kuba Ober wrote: > > I didn't know LyX was that clean internally. For most other apps > > that would be close to a rewrite of the core parts. > > Guess what we did in the 1.4 cycle. Ain't it great to see the payoff? :) -- John Weiss
Re: LyX on Windows
On Mon, Jan 17, 2005 at 02:09:33PM +0100, Lars Gullik Bjønnes wrote: > > I feel we are beginning on a slippery slope now... ok to support > windows if only minimal changes are needed... but now we see more and > more changes needed to support this. > > I am not sure that I am really happy about this "progress" Nor should you be. Doing true full-Windows support in an inherently-unix program is a very thorny, messy situation. You start running into the need to create a totally indenpendent platform-layer, doing the equivalent of standard Posix functions with pure Win-libs often requires odd gymnastics... I could go on. Suffice it to say that it's enough to keep a CompSci PhD fully employed at one place I used to work. Best to keep things simple for now, as Lars says. -- John Weiss
Re: [wishlist] server-client-architecture for LyX
On Fri, Jan 14, 2005 at 10:53:52AM +0100, Lars Gullik Bjønnes wrote: I'll describe it as a change in viewpoint: instead of having the core call the frontend (sounds a bit backwards, right?), we change it so that it is the frontend that calls the core. My vision is that the core is almost just a library that the frontend calls into. A Fine Idea. I approve wholeheartedly. (Not that you needed my approval. ;) ) -- John Weiss
Re: [rework docs] questions part two
On Thu, Jan 13, 2005 at 09:05:05AM +0100, Georg Baum wrote: John Weiss wrote: 1. External LaTeX packages have no place in LyX. The question was not to include the LaTeX files, but the layout files. 2. What the heck is a beamer? A very nice and powerful presentation class, and even easy to use for beginners. So, like I said in my reply to Uwe: the heir-apparent for that beast, SLiTeX? -- John Weiss
Re: [rework docs] questions part one
On Fri, Jan 14, 2005 at 10:09:29AM +0100, Lars Gullik Bjønnes wrote:
John Weiss [EMAIL PROTECTED] writes:
We (or I) do not want us to require a
lot of ERT to make the printed doc look nice, if ERT is needed then we
are missing features.
That was certainly the case when I last touched the docs, Lars.
There's one feature that we *do* need added: formatting environments
like \begin{fussy}...\end{fussy} or
\begin{flushleft}...\end{flushleft} that span paragraph environment
(or exist for only a few lines inside of one). There are times when
you need to remove justification or hyphenation for only a few lines.
(And, yes, I'm being glib, not thorough, again.)
--
John Weiss
Re: [rework docs] questions part two
On Thu, Jan 13, 2005 at 03:46:00AM +0100, Uwe Stöhr wrote: John Weiss wrote: 2. What the heck is a beamer? Just because you think it's the greatest-thing-since-sliced-bread doesn't mean everyone else does. Or even knows it exists. (Your bias is showing, Uwe!) (Nobody forces you to add caustic comment to your questions.) I blame it on That Horrible Horrible place I quit working for, (from which I fled screaming). That place makes people mean. (That, and I'm lacking sleep. Never a good combo.) Beamer is a class for creating presentations. It is a new package but became one of the most popular in the LaTeX community (browse e.g. comp.text.tex). Beamer is developed to work together with LyX and also the beamer userguide incorporate LyX. We jaded longtime LyX'ers have seen it all before. First Seminar, then Foils/FoilTeX. Now Beamer. Replacements for that old, creaky kludge known as SLiTeX crop up about 1 per year. For some odd reason, no single one ever seems to take hold. Heavens only knows why. It's not like SLiTeX isn't obtuse, arcane, subpar, and generally awful. If Beamer is the heir-apparent to SLiTeX, trust me, we'll add full support for it to LyX when the time comes. Then we can finally chuck support for that hack, SLiTeX (which we only keep because [a] it's an official part of LaTeX; and [b] too many hidebound professors refuse to learn anything new :P bleh). If it were really all that critical (like e.g. geometry.sty), it'd already have integrated LyX support. If it's The Future, the devteam will discover it soon enough... So I shouldn't make proposals? Proposals are made as questions. You made an assertion. :) -- John Weiss
Re: [wishlist] server-client-architecture for LyX
On Fri, Jan 14, 2005 at 10:53:52AM +0100, Lars Gullik Bjønnes wrote: > I'll describe it as a change in viewpoint: instead of having the core > call the frontend (sounds a bit backwards, right?), we change it so > that it is the frontend that calls the core. > > My "vision" is that the core is almost just a library that the > frontend calls into. A Fine Idea. I approve wholeheartedly. (Not that you needed my approval. ;) ) -- John Weiss
Re: [rework docs] questions part two
On Thu, Jan 13, 2005 at 09:05:05AM +0100, Georg Baum wrote: > John Weiss wrote: > > > 1. External LaTeX packages have no place in LyX. > > The question was not to include the LaTeX files, but the layout files. > > > 2. What the heck is a beamer? > > A very nice and powerful presentation class, and even easy to use for > beginners. So, like I said in my reply to Uwe: the heir-apparent for that beast, SLiTeX? -- John Weiss
Re: [rework docs] questions part one
On Fri, Jan 14, 2005 at 10:09:29AM +0100, Lars Gullik Bjønnes wrote:
> John Weiss <[EMAIL PROTECTED]> writes:
>
> We (or I) do not want us to require a
> lot of ERT to make the printed doc look nice, if ERT is needed then we
> are missing features.
That was certainly the case when I last touched the docs, Lars.
There's one feature that we *do* need added: formatting environments
like \begin{fussy}...\end{fussy} or
\begin{flushleft}...\end{flushleft} that span paragraph environment
(or exist for only a few lines inside of one). There are times when
you need to remove justification or hyphenation for only a few lines.
(And, yes, I'm being glib, not thorough, again.)
--
John Weiss
Re: [rework docs] questions part two
On Thu, Jan 13, 2005 at 03:46:00AM +0100, Uwe Stöhr wrote: > John Weiss wrote: > >2. What the heck is a beamer? > > > >Just because you think it's the greatest-thing-since-sliced-bread > >doesn't mean everyone else does. Or even knows it exists. (Your bias > >is showing, Uwe!) > > (Nobody forces you to add caustic comment to your questions.) I blame it on That Horrible Horrible place I quit working for, (from which I fled screaming). That place makes people mean. (That, and I'm lacking sleep. Never a good combo.) > Beamer is a class for creating presentations. It is a new package but > became one of the most popular in the LaTeX community (browse e.g. > comp.text.tex). Beamer is developed to work together with LyX and also > the beamer userguide incorporate LyX. We jaded longtime LyX'ers have seen it all before. First Seminar, then Foils/FoilTeX. Now Beamer. Replacements for that old, creaky kludge known as SLiTeX crop up about 1 per year. For some odd reason, no single one ever seems to take hold. Heavens only knows why. It's not like SLiTeX isn't obtuse, arcane, subpar, and generally awful. If Beamer is the heir-apparent to SLiTeX, trust me, we'll add full support for it to LyX when the time comes. Then we can finally chuck support for that hack, SLiTeX (which we only keep because [a] it's an official part of LaTeX; and [b] too many hidebound professors refuse to learn anything new :P ). > >If it were really all that critical (like e.g. geometry.sty), it'd > >already have integrated LyX support. If it's The Future, the devteam > >will discover it soon enough... > > So I shouldn't make proposals? Proposals are made as questions. You made an assertion. :) -- John Weiss
Re: [rework docs] reasons, plans, questions
On Thu, Jan 13, 2005 at 10:07:27AM +0100, Jean-Marc Lasgouttes wrote: Uwe == Uwe Stöhr [EMAIL PROTECTED] writes: Uwe John Weiss wrote: Doesn't follow a strucutred concept, eh? Maybe you should read the mailling list archives before insulting me. Uwe Sorry I wouldn't harm anybody. I didn't know that there is an Uwe active doc maintainer. I asked that on the docs- list a year ago Uwe and nobody replied. Are you the current doc maintainer? You are right that there is no active documentation maintainer, and it has been so for several years. John takes offense at the fact that you described his cherished baby as 'not structured'... No, more that he's saying no structure exists, when historical evidence (and my own memory of all that work!) points to the contrary. So the conclusion is that your activity on the docs is much needed and very appreciated, but you should not criticize John's work, at least in public ;) Not at all! If my original design plan for the docs has drifted too far from present needs, then by all means, Refactor Away! Which is exactly what we do with the code itself. Just be sure not to repeat the Mistakes of the Past as you change things. *That* drives me nutz. g ;) -- John Weiss
Re: Creating a std::string from unsigned char[4097] ?
On Thu, Jan 13, 2005 at 10:06:09AM +0100, Lars Gullik Bjønnes wrote: John Weiss [EMAIL PROTECTED] writes: | On Fri, Jan 07, 2005 at 05:18:23PM +0100, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Given this, which is MacOS X code to fill 'application_support': | unsigned char application_support[PATH_MAX + 1]; | OSStatus const status_code = | FSRefMakePath(fsref, application_support, PATH_MAX); | what's the correct way to create a std::string? | std::string(application_support) fails. Do you know its length? std::string(application_support, application_support + length); | IIRC, there's a template member fn. std::string::assign() or | std::string::insert() [I forget which] that takes a begin and end | iterator. You could use that. For the end-iterator, just use | (application_support + PATH_MAX). What do you think the above snippet use? Oh, you mean the one you ... no, wait, that just has, +length in it. Though I suppose you could mean use PATH_MAX for length there... Is there a templatized c'tor for std::string? I don't recall, and Strousdrup (the book, not the guy) is a tad difficult to lug around with the laptop to and from work each day. | Afterward, just do a std::string::find_first_of() to search for the | 1st '\0', then std::string::erase() from that point onward. PATH_MAX does not seem like a good idea. (and then you must at least zero out application_support first.) Umm, Lars, the constructor for POD arrays *always* zeros out the elements, remember? (bitterIt's in the Standard; I know. I spent the summer studying the bloody thing in prep for interviews. Fat load-o-good that did me.../bitter) Please try it out and test it for yourself. I'm just tossing off the idea. It's the first thing I'd try if faced with a strange API that wanted an unsigned char * to use as a buffer. -- John Weiss
Re: [rework docs] reasons, plans, questions
On Thu, Jan 13, 2005 at 03:34:24AM +0100, Uwe Stöhr wrote: John Weiss wrote: Doesn't follow a structured concept, eh? Maybe you should read the mailling list archives before insulting me. Sorry I wouldn't harm anybody. I didn't know that there is an active doc maintainer. I asked that on the docs- list a year ago and nobody replied. Are you the current doc maintainer? Sure, go ahead and be snide. I suppose I deserve it... No, Uwe, there's no one actively maintaining the docs. There hasn't been for a few years now. But that could be for two reasons: (1) I and my helpers did our jobs right 7 years ago and came up with something which, while scratched and dinged up in places, is still servicable. Or (2) I didn't do my job right and the docs are so bad-off as to be useless, yet the User community is afraid to take on the daunting task of writing new ones. I don't subscribe to the LyX user's list (too much traffic, and I have enough trouble keeping up with the devel docs lists these days), so I'm not hearing the howls of pain caused by the existing docs that you seem to be. I missed a structured concept in that way, that I often have to search in all three parts, the UserGuide, Customization and Extended for keywords to find the information. For a normal user it is often not clear what is extended or what might be in the UserGuide. - Partly, this is semantics. You should've seen the Great Naming Debate that went on for User Guide and Extended. bleh Boils down, again, to having an international user base who put slightly different connotations on English words depending on what they translate them to in their heads. You are not now, nor ever will fix that, Uwe. - Partly, its changes introduced to the Introduction.lyx manual. (I don't remember it being as long as what I see right now, just having looked. I also remember trying to keep it to a bare minimum, as I expected Introduction to be the frequently-accessed first-point-of-contact, not a one-off throwaway, which it's been turned into. The whole Philosophy of LyX stuff belongs in either the UG or the Tutorial, not in Intro) - Mainly, though, it's due to a failing in my vision: The Reference was supposed to be the search for j-random-feature, find which docs cover it index you seem to be missing. Reference was supposed to be a community-wide maintenance effort. It wouldn't be pretty, but it'd be thorough. I even included a sample, Here's how to add an entry, section in the thing. But no... no one bothered to start there. No. Too busy painting the house to bother replacing the rotting clapboards they're trying to paint over... Not all of the menus are described because one doesn't need to know what they all are. But that's the intention of a UserGuide! Now you're being unfair by taking what I said out of context. You do not need to know what they all are all at once in order to use LyX as an effective writing tool. You do not need faxing in order to write a paper, and playing around with character formats is a Great Time Black Hole, one regularly used to avoid doing the real work: writing the content. Another example: After three years using LyX, I now found out what the menu Navigate-Bookmarks does and how I can change the number of available bookmarks. This feature is very useful for me, but wasn't described in the docs. 1. Was added in the past year or so. We've had no docteam in that time. 2. Useful, yes. Necessary, no. You don't need a navigation tool to figure out what you want to say in the regular flow of text, and what you want to put in a bullet list. Which is rather the whole point of LyX: forget the exterior frills. Focus on the content. (Read at bottom for some related gripes (not at you).) The User's Guide was supposed to contain only those features that give you the advantage of focussing on content over appearance. (sigh But I said that before, several times, and you ignored me, several times. Why should now be any different...) As you can see undescribed menus won't be used. and ironic comments. (These comments are often funny but shouldn't be part of a manual.) ...because manuals should be as dry as dust, and so boring that nobody looks at them? Yes of course ;-) I mean commands like If you use Export-PostScript you can start drinking a coffee (translated from the german docs). If users don't laugh about it, it scares them off. That's poor translation. Read the original English. Which, now that I think of it, may be a bit dated considering modern processor speed. Nobody read a UserGuide from the beginning to the end. Except of the tutorial, docs are used as reference book. Because most of them are as dry as dust, boring, and treat the reader like a lobotomized mentally-disabled-person. I've already done adding some of the customization stuff to the UserGuide. In my opinion sections like the one describing
Re: [rework docs] reasons, plans, questions
On Wed, Jan 12, 2005 at 05:20:49PM -0800, Jeremy C. Reed wrote: On Wed, 12 Jan 2005, John Weiss wrote: Use a separate doc and include it via a master doc. I was thinking about that. Other than the book will have a lot of redundant information. Yes, that is a problem, isn't it? One of the primary design constraints of the LyX Docs is that it be readable both in print and online. It serves both of these purposes. I understand. : : A master document including the parts is a good idea; maybe the individual parts can still be rewritten some so they don't repeat to much. Alas, no. The repetition was added, intentionally, after I was told that I had the wrong balance. See, I originally came up with a compromise: just enough repetition so that a user wouldn't need to go flipping to a different document *most* of the time. Keeping repetition to a minimum, referencing other docs, was a maintenance strategy (less repetition == less editing when repeated parts need to change). However, the balance I came up with assumed that our users remember things as well as I do ... or used to 7 years ago :P ... which wasn't correct. So others later added in more repetition. Change the individual docs to reduce the repetition, and you'll soon be hearing shrieks of pain from LyX users. This is, yet again, one of those compromises we made between read online and read printed version. -- John Weiss
Re: Language Lesson
On Thu, Jan 13, 2005 at 09:18:50AM +0200, Martin Vermeer wrote: On Wed, 2005-01-12 at 05:45, Andreas Vox wrote: What, *any* of those? Doesn't your orthography comittee tell you which one is the right one? Ours would. And then you would proceed ignoring them and go on writing it the way you always have written it... FYI: Just because there's variation in English orthography doesn't mean, Anything goes. It just means we have multiple ways of writing the same phoneme. Hence this lesson, in which we learn that ee, ie and ey can have the same pronounciation, but ee and ay never do. :) -- John Weiss
Reviewing the Past [was: [rework docs] reasons, plans, questions]
OTOH, if you're really serious about taking on updating the docs, Uwe, I have some suggestions. First, see where we've been. I've written copious bytes describing the design and goals of the docs. It'd be foolish not to look at that. Wanna know why some part of the docs is the way it is? Ask me; I may even remember. :D Second, take a page from the latest hot programming technique: Refactor, Refactor, Refactor. Do small incremental changes, with frequent reviews in-between. And by reviews, I mean the user base (as in the user's mailing list). Third, let the user's mailing list guide changes in organization, layout, and underlying design. Get a consensus for changes, both just-completed and planned, from the community at large. Most of the developers (and, soon, me as well) won't have the time to do more than give changes a cursory glance. Fourth, Beware Wannaponies! A Wannaponie: Think of a little girl, jumping up and down, shouting, I Wanna Ponie! I WANNA PONIE!!! If you ask people, what do you want in the docs? you'll get all sorts of hairbrained Wannaponies, most of them conflicting each others' goals. Remember, docs have a design, too. You'll need to ignore those suggestions that conflict with the design. Just like Lars has to reject patches that conflict with the code design. Fifth, I forget fifth. Vielleicht erinnere ich mich daran spter... -- John Weiss
Re: [rework docs] reasons, plans, questions
On Thu, Jan 13, 2005 at 10:07:27AM +0100, Jean-Marc Lasgouttes wrote: > >>>>> "Uwe" == Uwe Stöhr <[EMAIL PROTECTED]> writes: > > Uwe> John Weiss wrote: > >> Doesn't follow a strucutred concept, eh? Maybe you should read the > >> mailling list archives before insulting me. > > Uwe> Sorry I wouldn't harm anybody. I didn't know that there is an > Uwe> active doc maintainer. I asked that on the docs- list a year ago > Uwe> and nobody replied. Are you the current doc maintainer? > > You are right that there is no active documentation maintainer, and it > has been so for several years. John takes offense at the fact that you > described his cherished baby as 'not structured'... No, more that he's saying no structure exists, when historical evidence (and my own memory of all that work!) points to the contrary. > So the conclusion is that your activity on the docs is much needed and > very appreciated, but you should not criticize John's work, at least > in public ;) Not at all! If my original design plan for the docs has drifted too far from present needs, then by all means, Refactor Away! Which is exactly what we do with the code itself. Just be sure not to repeat the Mistakes of the Past as you change things. *That* drives me nutz.;) -- John Weiss
Re: Creating a std::string from unsigned char[4097] ?
On Thu, Jan 13, 2005 at 10:06:09AM +0100, Lars Gullik Bjønnes wrote: > John Weiss <[EMAIL PROTECTED]> writes: > > | On Fri, Jan 07, 2005 at 05:18:23PM +0100, Lars Gullik Bjønnes wrote: > >> Angus Leeming <[EMAIL PROTECTED]> writes: > >> > >> | Given this, which is MacOS X code to fill 'application_support': > >> > > >> | unsigned char application_support[PATH_MAX + 1]; > >> | OSStatus const status_code = > >> | FSRefMakePath(, application_support, PATH_MAX); > >> > > >> | what's the correct way to create a std::string? > >> > > >> | std::string(application_support) fails. > >> > >> Do you know its length? > >> > >>std::string(application_support, application_support + length); > > > | IIRC, there's a template member fn. std::string::assign() or > | std::string::insert() [I forget which] that takes a begin and end > | iterator. You could use that. For the end-iterator, just use > | (application_support + PATH_MAX). > > What do you think the above snippet use? Oh, you mean the one you ... no, wait, that just has, "+length" in it. Though I suppose you could mean "use PATH_MAX for length" there... Is there a templatized c'tor for std::string? I don't recall, and Strousdrup (the book, not the guy) is a tad difficult to lug around with the laptop to and from work each day. > | Afterward, just do a std::string::find_first_of() to search for the > | 1st '\0', then std::string::erase() from that point onward. > > PATH_MAX does not seem like a good idea. (and then you must at least > zero out application_support first.) Umm, Lars, the constructor for POD arrays *always* zeros out the elements, remember? (It's in the Standard; I know. I spent the summer studying the bloody thing in prep for interviews. Fat load-o-good that did me...) > Please try it out and test it for yourself. I'm just tossing off the idea. It's the first thing I'd try if faced with a strange API that wanted an unsigned char * to use as a buffer. -- John Weiss
Re: [rework docs] reasons, plans, questions
On Thu, Jan 13, 2005 at 03:34:24AM +0100, Uwe Stöhr wrote: > John Weiss wrote: > > >Doesn't follow a structured concept, eh? > >Maybe you should read the mailling list archives before insulting me. > > Sorry I wouldn't harm anybody. I didn't know that there is an active doc > maintainer. I asked that on the docs- list a year ago and nobody replied. > Are you the current doc maintainer? Sure, go ahead and be snide. I suppose I deserve it... No, Uwe, there's no one actively maintaining the docs. There hasn't been for a few years now. But that could be for two reasons: (1) I and my helpers did our jobs right 7 years ago and came up with something which, while scratched and dinged up in places, is still servicable. Or (2) I didn't do my job right and the docs are so bad-off as to be useless, yet the User community is afraid to take on the daunting task of writing new ones. I don't subscribe to the LyX user's list (too much traffic, and I have enough trouble keeping up with the devel & docs lists these days), so I'm not hearing the howls of pain caused by the existing docs that you seem to be. > I missed a structured concept in that way, that I often have to search > in all three parts, the UserGuide, Customization and Extended for > keywords to find the information. For a normal user it is often not > clear what is extended or what might be in the UserGuide. - Partly, this is semantics. You should've seen the Great Naming Debate that went on for "User Guide" and "Extended". Boils down, again, to having an international user base who put slightly different connotations on English words depending on what they translate them to in their heads. You are not now, nor ever will fix that, Uwe. - Partly, its changes introduced to the "Introduction.lyx" manual. (I don't remember it being as long as what I see right now, just having looked. I also remember trying to keep it to a bare minimum, as I expected "Introduction" to be the frequently-accessed first-point-of-contact, not a one-off throwaway, which it's been turned into. The whole "Philosophy of LyX" stuff belongs in either the UG or the Tutorial, not in Intro) - Mainly, though, it's due to a failing in my vision: The Reference was supposed to be the "search for j-random-feature, find which docs cover it" index you seem to be missing. Reference was supposed to be a community-wide maintenance effort. It wouldn't be pretty, but it'd be thorough. I even included a sample, "Here's how to add an entry," section in the thing. But no... no one bothered to start there. No. Too busy painting the house to bother replacing the rotting clapboards they're trying to paint over... > >Not all of the menus are described because one doesn't need to know > >what they all are. > > But that's the intention of a UserGuide! Now you're being unfair by taking what I said out of context. You do not need to know what they all are all at once in order to use LyX as an effective writing tool. You do not need faxing in order to write a paper, and playing around with character formats is a Great Time Black Hole, one regularly used to avoid doing the real work: writing the content. > Another example: After three years using LyX, I now found out what the > menu Navigate->Bookmarks does and how I can change the number of > available bookmarks. This feature is very useful for me, but wasn't > described in the docs. 1. Was added in the past year or so. We've had no docteam in that time. 2. Useful, yes. Necessary, no. You don't need a navigation tool to figure out what you want to say in the regular flow of text, and what you want to put in a bullet list. Which is rather the whole point of LyX: forget the exterior frills. Focus on the content. (Read at bottom for some related gripes (not at you).) The User's Guide was supposed to contain only those features that give you the advantage of focussing on content over appearance. ( But I said that before, several times, and you ignored me, several times. Why should now be any different...) > As you can see undescribed menus won't be used. > > >>and ironic comments. (These comments are often funny but > >>shouldn't be part of a manual.) > > > >...because manuals should be as dry as dust, and so boring that nobody > >looks at them? > > Yes of course ;-) I mean commands like "If you use Export->PostScript > you can start drinking a coffee" (translated from the german docs). If > users don't laugh about it, it scares them off. That's poor translation. Read the original English. Which, now that I think of it, may be a bit dated considering modern processor speed. > Nobody read a UserGuide from the beginning to the end. Except of the > tutorial, docs
Re: [rework docs] reasons, plans, questions
On Wed, Jan 12, 2005 at 05:20:49PM -0800, Jeremy C. Reed wrote: > On Wed, 12 Jan 2005, John Weiss wrote: > > > Use a separate doc and include it via a master doc. > > I was thinking about that. Other than the book will have a lot of > redundant information. Yes, that is a problem, isn't it? > > One of the primary design constraints of the LyX Docs is that it be > > readable both in print and online. It serves both of these purposes. > > I understand. : : > A master document including the parts is a good idea; maybe the individual > parts can still be rewritten some so they don't repeat to much. Alas, no. The repetition was added, intentionally, after I was told that I had the wrong balance. See, I originally came up with a compromise: just enough repetition so that a user wouldn't need to go flipping to a different document *most* of the time. Keeping repetition to a minimum, referencing other docs, was a maintenance strategy (less repetition ==> less editing when repeated parts need to change). However, the balance I came up with assumed that our users remember things as well as I do ... or used to 7 years ago :P ... which wasn't correct. So others later added in more repetition. Change the individual docs to reduce the repetition, and you'll soon be hearing shrieks of pain from LyX users. This is, yet again, one of those compromises we made between "read online" and "read printed version". -- John Weiss
Re: Language Lesson
On Thu, Jan 13, 2005 at 09:18:50AM +0200, Martin Vermeer wrote: > On Wed, 2005-01-12 at 05:45, Andreas Vox wrote: > > What, *any* of those? Doesn't your orthography comittee tell you which > > one is the right one? Ours would. > > And then you would proceed ignoring them and go on writing it the way > you always have written it... FYI: Just because there's variation in English orthography doesn't mean, "Anything goes." It just means we have multiple ways of writing the same phoneme. Hence this lesson, in which we learn that "ee", "ie" and "ey" can have the same pronounciation, but "ee" and "ay" never do. :) -- John Weiss
Reviewing the Past [was: [rework docs] reasons, plans, questions]
OTOH, if you're really serious about taking on updating the docs, Uwe, I have some suggestions. First, see where we've been. I've written copious bytes describing the design and goals of the docs. It'd be foolish not to look at that. Wanna know why some part of the docs is the way it is? Ask me; I may even remember. :D Second, take a page from the latest hot programming technique: Refactor, Refactor, Refactor. Do small incremental changes, with frequent reviews in-between. And by "reviews," I mean the user base (as in the user's mailing list). Third, let the user's mailing list guide changes in organization, layout, and underlying design. Get a consensus for changes, both just-completed and planned, from the community at large. Most of the developers (and, soon, me as well) won't have the time to do more than give changes a cursory glance. Fourth, Beware Wannaponies! A "Wannaponie": Think of a little girl, jumping up and down, shouting, "I Wanna Ponie! I WANNA PONIE!!!" If you ask people, "what do you want in the docs?" you'll get all sorts of hairbrained Wannaponies, most of them conflicting each others' goals. Remember, docs have a design, too. You'll need to ignore those suggestions that conflict with the design. Just like Lars has to reject patches that conflict with the code design. Fifth, I forget fifth. Vielleicht erinnere ich mich daran spïter... -- John Weiss
Re: [rework docs] include mathed documentation
On Wed, Jan 12, 2005 at 10:31:37AM +0100, [EMAIL PROTECTED] wrote: On Tue, 11 Jan 2005, [UTF-8] Uwe Sthr wrote: I covers now nearly all math constructs. I want to replace the mathed section in the userguide by this documentation. In my opinion the tutorial has a very good introduction to mathed: It explains navigating in formulas, the math-panel and the most common used constructs (fractions etc.). So that we could go deeper in the userguide. Mathed supports so many constructs that aren't explained in the docs at the moment. Are there any objections against this plan? I doubt that... the only concern I can think of is that it might be too much/advanced? That's what I was about to say. We (a Maths professor and myself) intentionally *did* *not* cover all possible mathed features in the User's Guide precisely because of scope. Better to move the more esoteric features into the Extended doc. -- John Weiss
Re: Language Lesson
On Wed, Jan 12, 2005 at 11:35:51AM +0100, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | While we're at it, however, what's a lanuage? that is the lesson you just received. Methinks Angus refers to the missing 'g' in language in one of sentences. I blame it on the engineers. They teach them to drive the trains so that they shake as much as possible here on these New York lines. (If you want to look at my commute on Mapquest, I catch a commuter train from Beacon, NY, USA, to Grand Central Terminal on 42nd St., NY, NY. The train runs along the eastern bank of the Hudson River. Then I hop onto the subway ... the (4) or (5) express ... from Grand Central/42 St. to Bowling Green, at the very southern tip of Manhattan. The whole trip, if I catch an express train, takes about 1hr 30min. Hence the use of a laptop during the trip to/from Manhattan.) -- John Weiss
Re: Language Lesson
On Wed, Jan 12, 2005 at 03:45:00AM +, Andreas Vox wrote: What, *any* of those? Doesn't your orthography comittee tell you which one is the right one? Ours would. Yeah, but no one pays any attention to them. :) Besides, that's an informal enough phrase, anyhow, so as not to have nor need a fixed orthography. Ok, dokey is an affirmative reply to someone named, dokey. ;) In that case our othography committee would tell us to use uppercase for Dokey. Yeah, well, so would ours, but people spell their names all sortsa ways. I guess they could be called, dokey (pronounced D/oh-/key, not d/oo/key) withouth that being the actual name or anything. ;) But of course German kids are not allowed -- by law -- to be baptized Dokey anyway. Most sensible. But here in the US, we have so many people with ancestors hailing from so many parts of the world that just about any name will work. As long as it's not similar sounding to something lewd or some other word that schoolmates can use to taunt the poor dear with. And Amerrricans train their kids to be cruel. Maybe a typo for Okay, do key ? Can you say do key instead of press key ? Also possible. Hand't thought of that, tho. ;) -- John Weiss
Re: [rework docs] questions part one
Uwe:
For future reference:
When I was working on this 7 years ago, I added various ERT to ensure
a good-looking print version. (I proofread the print version using
ghostscript or xdvi back then.) Of course, someone probably decided
to be helpful and remove all of my '\raggedright' and
'\begin{sloppypar}' ... '\end{sloppypar}' ERT. Yet Another Example of
someone focussing on only their own narrow agenda (Ze Online Version
Must Look Perfect) to the detriment of everything else (the print
version, in this case).
Bear in mind that you will need to do proofread a DVI/PS/PDF version
for overly-long lines of code, for justification to go haywire on
some individual lines, and similar print flubs. You'll need to do
some LaTeX tweaking on those. You may also need to elminate old LaTeX
tweaks that are no longer relevant due to inserted/deleted
preceeding/following text. Though, I tried to minimize those by using
manual linebreaks on text that went wonky in print.
--
John Weiss
Re: Language Lesson
On Wed, Jan 12, 2005 at 02:11:46PM +0100, [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005, Lars Gullik Bjønnes wrote: Andreas Vox [EMAIL PROTECTED] writes: | Maybe a typo for Okay, do key ? Can you say do key instead of press key ? Why would you do Key? What wrong has Key ever done to you? Maybe Key thinks Andreas is cute... Maybe Key is of the opposite sex? What's that got to do with it? We're here! We're Queer! And we use LyX! :) -- John Weiss
Re: [rework docs] include mathed documentation
On Wed, Jan 12, 2005 at 10:31:37AM +0100, [EMAIL PROTECTED] wrote: > On Tue, 11 Jan 2005, [UTF-8] Uwe StïÃïÂïhr wrote: > > > I covers now nearly all math constructs. I want to replace the mathed > > section in the userguide by this documentation. > > In my opinion the tutorial has a very good introduction to mathed: It > > explains navigating in formulas, the math-panel and the most common used > > constructs (fractions etc.). So that we could go deeper in the > > userguide. Mathed supports so many constructs that aren't explained in > > the docs at the moment. > > > > Are there any objections against this plan? > > I doubt that... the only concern I can think of is that it might be too > much/advanced? That's what I was about to say. We (a Maths professor and myself) intentionally *did* *not* cover all possible mathed features in the User's Guide precisely because of scope. Better to move the more esoteric features into the Extended doc. -- John Weiss
Re: Language Lesson
On Wed, Jan 12, 2005 at 11:35:51AM +0100, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | While we're at it, however, what's a "lanuage"? > > that is the lesson you just received. Methinks Angus refers to the missing 'g' in "language" in one of sentences. I blame it on the engineers. They teach them to drive the trains so that they shake as much as possible here on these New York lines. (If you want to look at my commute on Mapquest, I catch a commuter train from Beacon, NY, USA, to Grand Central Terminal on 42nd St., NY, NY. The train runs along the eastern bank of the Hudson River. Then I hop onto the subway ... the (4) or (5) express ... from Grand Central/42 St. to Bowling Green, at the very southern tip of Manhattan. The whole trip, if I catch an express train, takes about 1hr 30min. Hence the use of a laptop during the trip to/from Manhattan.) -- John Weiss
Re: Language Lesson
On Wed, Jan 12, 2005 at 03:45:00AM +, Andreas Vox wrote: > > What, *any* of those? Doesn't your orthography comittee tell you which > one is the right one? Ours would. Yeah, but no one pays any attention to them. :) Besides, that's an informal enough phrase, anyhow, so as not to have nor need a fixed orthography. > < > < "Ok, dokey" is an affirmative reply to someone named, "dokey". ;) > < > > In that case our othography committee would tell us to use uppercase > for "Dokey". Yeah, well, so would ours, but people spell their names all sortsa ways. I guess they could be called, "dokey" (pronounced "D/oh-/key," not "d/oo/key") withouth that being the actual name or anything. ;) > But of course German kids are not allowed -- by law -- to be > baptized "Dokey" anyway. Most sensible. But here in the US, we have so many people with ancestors hailing from so many parts of the world that just about any name will work. As long as it's not similar sounding to something lewd or some other word that schoolmates can use to taunt the poor dear with. And Amerrricans train their kids to be cruel. > Maybe a typo for "Okay, do key" ? Can you say "do key" instead of > "press key" ? Also possible. Hand't thought of that, tho. ;) -- John Weiss
Re: [rework docs] questions part one
Uwe:
For future reference:
When I was working on this 7 years ago, I added various ERT to ensure
a good-looking print version. (I proofread the "print" version using
ghostscript or xdvi back then.) Of course, someone probably decided
to "be helpful" and remove all of my '\raggedright' and
'\begin{sloppypar}' ... '\end{sloppypar}' ERT. Yet Another Example of
someone focussing on only their own narrow agenda (Ze Online Version
Must Look Perfect) to the detriment of everything else (the print
version, in this case).
Bear in mind that you will need to do proofread a DVI/PS/PDF version
for overly-long lines of code, for justification to go haywire on
some individual lines, and similar print flubs. You'll need to do
some LaTeX tweaking on those. You may also need to elminate old LaTeX
tweaks that are no longer relevant due to inserted/deleted
preceeding/following text. Though, I tried to minimize those by using
manual linebreaks on text that went wonky in print.
--
John Weiss
Re: Language Lesson
On Wed, Jan 12, 2005 at 02:11:46PM +0100, [EMAIL PROTECTED] wrote: > On Wed, 12 Jan 2005, Lars Gullik Bjønnes wrote: > > > Andreas Vox <[EMAIL PROTECTED]> writes: > > > > | Maybe a typo for "Okay, do key" ? Can you say "do key" instead of "press > > key" ? > > > > Why would you "do Key"? What wrong has Key ever done to you? Maybe Key thinks Andreas is cute... > Maybe Key is of the opposite sex? What's that got to do with it? We're here! We're Queer! And we use LyX! :) -- John Weiss
Re: [rework docs] reasons, plans, questions
On Sun, Jan 09, 2005 at 10:34:29PM +0100, Uwe Stöhr wrote: Andre Poenitz wrote: Indeed. Having it in the UserGuide only serves people masochistic enough to read it either as .lyx in a text editor before installation or after installation to see what might have sped up the installation... You are right, I dropped this now. I think what you want to do instead, Uwe, is to add a chapter to Customization roughly outlining what all of the different addons are, by category, and why one might want them. -- John Weiss
Re: [rework docs] questions part two
On Sun, Jan 09, 2005 at 03:12:07PM +0100, Uwe Stöhr wrote: I wrote: The menu Navigate - Refs seems to be broken. I expect that this menu let me jump from cross- and citation-reference to the next, but nothing happens. Sorry. The menu works., but it doesn't jump from reference to reference. It jumps from one label to the next. So the menu name is a bit confusing. It should better have the name Label. And this is where your job as doc-editor comes in. ;) Describe that thang! -- John Weiss
Re: [rework docs] questions part two
On Mon, Jan 10, 2005 at 10:29:08PM +0100, Uwe Stöhr wrote: That I can copy a section with a section heading, keeping the format of the heading. At the moment the format of sections headings are lost by copy/cut and paste. I hope this now fixed now by Georg's patch (many thanks for looking at this). Uwe: In M$ Word, formatting information is implicitly embedded just before the end of a line. In LyX, formatting information is implicitly embedded in-between the beginning of the line and the end of the previous line. I'm guessing that you're used to copying formatting using a Home; S-End; C-c. For LyX, retrain yourself to do End; S-Up; S-End; C-c (or, if you're using non-CUA bindings, replace the C-c with a M-w). If, however, I'm guessing wrong, and you are positioning the start of your region at the end of the previous line, or if mid-region section-headings lose their paragraph style, then this is indeedy-deed a bug introduced in v1.4CVS. -- John Weiss
Re: [rework docs] questions part one
On Sun, Jan 09, 2005 at 12:14:48PM +0100, Juergen Spitzmueller wrote: I think gnu aspell has superceeded ispell for a lot of languages now, but there might still be languages that are not supported well (or at all) by aspell. In any case, it is good to have the choice. In the preferences I can choose between aspell, ispell and hspell. But as personal dictionary I can only set an ispell one. Why? I think that (gnu) aspell does not use this option (it uses the personal dictionary ~/.aspell.lang.pws by default). This might as well count for other spellchecker options. Don't know. Hmm... now that I read this, it makes me think that, perhaps, the details about the different flavors of spellchecker belong in Customization.lyx -- John Weiss
Re: [rework docs] reasons, plans, questions
On Sat, Jan 08, 2005 at 08:35:11PM +0100, Uwe Stöhr wrote: Reasons: First I just wanted to update the documentation for LyX QT 1.3.x and make a bit more platform independent. But while working on the UserGuide, I realized that it is really out of date. The last complete rework was done in 2000 for the LyX 1.0.x series. In the meantime many updates and new sections were added. But the documentation still misses many informations and doesn't follow a structured concept. Doesn't follow a strucutred concept, eh? Maybe you should read the mailling list archives before insulting me. E.g. not all menus are described and there is no explanation for the icon buttons under the menu bar. Ignoring the toolbar was a strategic move. Since tooltips will tell you what they do, it becomes obvious which menu items they're shortcuts for. If you don't know the corresponding menu item, then you clearly don't need it yet. Why are you wasting time messing around with arcane features? Get back to work on that document you're writing! ;) Not all of the menus are described because one doesn't need to know what they all are. One only needs to know where to find the features that one'll use most frequently while writing your average document. Again, a stragetic move, and one to give the docs a clearly-defined structure. I do agree, however, that 4 years of drift have rendered the documented menu locations of many features wrong. That certainly needs to be corrected. Plans: I would rework the Tutorial and the UserGuide. The UserGuide would contain a section with an overview of all menus and icon buttons. There is a chapter in the Reference manual for this. That is the logical place for it, as I said in the original description of the documents' strucutre. But I want to delete platform specifig stuff like Configuring the X keyboard etc. Configuring the X keyboard could probably go. Life on Linux X has improved rather significantly in the 7 years since we added that. and ironic comments. (These comments are often funny but shouldn't be part of a manual.) ...because manuals should be as dry as dust, and so boring that nobody looks at them? At last I want to merge the Customization and Extended manual. Some of its stuff will be part of the UserGuide. Bad Idea. I suggest you look through the mailing list archives for my earlier emails where I describe the structure of the docs. These two files were split off for a reason. I started once with a new layout for the UserGuide in koma-script book format. sarcasm ...because *everyone* is German and therefore uses a German-centric LaTeX class like koma-script. /sarcasm Uwe, if you are going to do this, and you want something that ALL of us can use, you need to start looking at the docs through the eyes of all of the users, not just from your own point of view. This is why I'm so critical. (While editor, I was equally critical of contributors for exactly the same reasons when they veered off course into their own narrow perspective.) Right now, I have doubts. I read a lot of high-flying ideas from you, with very little grounding in practicality. Let me give you an example of what I mean by practicality: The Customize the X keyboard for non-US-English. We added that because the lists were getting about 2-3 Hlp Me messages a month asking for this information. There was a practical reason for adding it to the docs, so in it went. There were practical reasons for the division of the docs. There were practical reasons for the names of the docs. I didn't personally agree with some of the names, but went with those changes, anyway, because my suggestions didn't convey the proper connotations to the wider audience of LyX users. As much as we'd all love to have someone, anyone, updating the docs, I have to play Lars here for a sec and ask: are you overdesigining? Do we really need this-or-that feature you want to add? And, in the case of the docs, can you put yourself and your own agenda (printable book) aside and make decisions grounded in practical, broad-user-community-consensus-based reasons? -- John Weiss
Re: [rework docs] questions part two
On Sun, Jan 09, 2005 at 12:56:11PM +0100, Georg Baum wrote: Am Samstag, 8. Januar 2005 22:43 schrieb Uwe Stöhr: I want the example and template LyX files that comes with the beamer package to be added to LyX CVS. These files works very well and the author of course allows this. Is this possible or are there some objections? I don't think that it is worth the effort: I concur: 1. External LaTeX packages have no place in LyX. Lars/Asger/Jean-Marc and a cast-of-thousands worked long and hard to ensure we'd never need to do this (hence the whole LaTeX-Config engine autogenerated manual). Why resurrect a long-rejected bad idea? 2. What the heck is a beamer? Just because you think it's the greatest-thing-since-sliced-bread doesn't mean everyone else does. Or even knows it exists. (Your bias is showing, Uwe!) If it were really all that critical (like e.g. geometry.sty), it'd already have integrated LyX support. If it's The Future, the devteam will discover it soon enough... -- John Weiss
Re: Creating a std::string from unsigned char[4097] ?
On Fri, Jan 07, 2005 at 05:18:23PM +0100, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Given this, which is MacOS X code to fill 'application_support': | unsigned char application_support[PATH_MAX + 1]; | OSStatus const status_code = | FSRefMakePath(fsref, application_support, PATH_MAX); | what's the correct way to create a std::string? | std::string(application_support) fails. Do you know its length? std::string(application_support, application_support + length); IIRC, there's a template member fn. std::string::assign() or std::string::insert() [I forget which] that takes a begin and end iterator. You could use that. For the end-iterator, just use (application_support + PATH_MAX). Afterward, just do a std::string::find_first_of() to search for the 1st '\0', then std::string::erase() from that point onward. Granted, it's not ideal, but it accomplishes what you want, and avoids the nasty reinterpret_cast()... -- John Weiss
Re: [rework docs] questions part one
On Sat, Jan 08, 2005 at 10:16:19PM +0100, Uwe Stöhr wrote: Spellchecker: In the current version of the UserGuide I found a lot of ispell-specific stuff that I would get rid of. Does the problems with ispell described there still exist? Or does everybody replaced ispell by the newer and generally better aspell? You are correct! Any mentions of ispell specifically should be replaced with more general text. You may want to occasionally make reference back to some initial section about spelling where you mention the different flavors of spellchecker out there and any subtleties that a user may have to pay attention to. May I suggest, once you know what your replacement prhases should be, doing a document-wide Find 'ispell' on every one of the manuals? Then, once you've finished all your edits, do the Find 'ispell' again to make sure you got them all. (This is the very same technique I used 7 years ago. Very good for such global doc-refactors.) -- John Weiss
Re: [rework docs] questions part two
On Sun, Jan 09, 2005 at 04:26:18PM +0100, Uwe Stöhr wrote: Georg Baum wrote: As I use LyXWin, could somebody please send me his file LaTeX-Configuration? This menu is broken in LyXWin and I need it to describe it in the docs. Thanks. I guess you don't mean the file that you can get via Help-LaTeX Configuration? No I mean exactly this one. In case no one's sent you theirs, I'm attaching the one from the laptop. -- John Weiss #LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 221 \textclass article \language english \inputencoding default \fontscheme default \graphics dvips \paperfontsize 0 \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 2 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle plain \layout Title Inventory of your LaTeX configuration \layout Author Automatically generated by LyX (do not edit). \layout Date October 5, 2004 \layout Standard This file describes the different LaTeX add-ons that LyX can handle. Below you'll find six sections: \layout Enumerate Some basic details about your LaTeX installation. In particular, you should make sure that your version of LaTeX is recent enough. \layout Enumerate Some common fonts that LyX knows about. This is rather sparse at the moment. \layout Enumerate The document classes that should be standard on any LaTeX implementation. This section is only here for completeness. \layout Enumerate Some optional document classes that LyX knows about. If one of these is marked as missing (the \begin_inset Quotes eld \end_inset Found \begin_inset Quotes erd \end_inset item is no) and you need its functionality, you can grab it at your nearest CTAN ftp site \begin_inset Foot collapsed true \layout Standard The participating hosts in the Comprehensive TeX Archive Network are: \layout LyX-Code ftp://ftp.dante.de/tex-archive \layout LyX-Code ftp://ctan.tug.org/tex-archive \layout LyX-Code ftp://ftp.tex.ac.uk/tex-archive \layout Standard There are also a zillion mirror sites which are listed at the three primary sites. \end_inset at the location indicated in the \begin_inset Quotes eld \end_inset CTAN \begin_inset Quotes erd \end_inset item. Note that only detected document classes can be selected as document layouts in LyX. \layout Enumerate The packages that have been stamped \begin_inset Quotes eld \end_inset required \begin_inset Quotes erd \end_inset by the LaTeX maintainers. These ones should definitely be present, but you may not have some of them if your LaTeX distribution is a bit old. \layout Enumerate Some packages that LyX uses when you try to change the margins of your document. The detection of these items does not yet affect the options available inside LyX. \layout Enumerate Some common LaTeX packages that you might need with LyX, and you might also want to add to your LaTeX installation. The detection of these items does not yet affect the options available inside LyX. \layout Standard Note that most of these packages will be available if you use a modern TeX distribution such as teTeX. If you decide to install one of the missing items, you should tell LyX about it. After the installation, please use the menu entry \family sans \bar under O \bar default ptions\SpecialChar \menuseparator \bar under R \bar default econfigure \begin_inset Foot collapsed true \layout Standard or, if you want to change the system-wide settings, issue the command \family typewriter ./configure \family default from the LyX system directory (by default \family typewriter /usr/local/lib/lyx/ \family default ) \end_inset and reload this file to see if the new package was recognized. If the \begin_inset Quotes eld \end_inset Found \begin_inset Quotes erd \end_inset items read \begin_inset Quotes eld \end_inset ??? \begin_inset Quotes erd \end_inset , it means that LyX could not do the inventory of your LaTeX configuration for some reason. If you are using teTeX, it might be that the new package you installed is not found. This is because you forgot to run the command \family typewriter texhash \family default , which tells teTeX to update its own configuration. \layout Section LaTeX version currently in use \layout Standard The LaTeX version that LyX will use is: \family typewriter 2001/06/01 \family default . Note that, for best results, you should be using at least LaTeX release \family typewriter 1995/12/01 \family default \begin_inset Foot collapsed true \layout Standard In case it is not clear to you, this number is the date at which the version has been released. \end_inset . In fact, earlier versions may work for many things, but will certainly fail in some cases. We feel that it is better to stick
Re: [rework docs] reasons, plans, questions
On Mon, Jan 10, 2005 at 09:41:56AM -0800, Jeremy C. Reed wrote: I though if the goal is to have a printed book, then the installation should be covered also. Use a separate doc and include it via a master doc. Jeremy, Uwe, you guys are MAKING ME VERY NERVOUS with your near-fixation on making a printable version to the exclusion of everything else. One of the primary design constraints of the LyX Docs is that it be readable both in print and online. It serves both of these purposes. The LyX Developers even added a feature into LyX ... the infamous menu arrow special character ... to serve this very purpose. Ignore online readability/navigability at your peril! -- John Weiss
Re: [rework docs] reasons, plans, questions
On Sun, Jan 09, 2005 at 10:34:29PM +0100, Uwe Stöhr wrote: > Andre Poenitz wrote: > > >Indeed. Having it in the UserGuide only serves people masochistic enough > >to read it either as .lyx in a text editor before installation or after > >installation to see what might have sped up the installation... > > You are right, I dropped this now. I think what you want to do instead, Uwe, is to add a chapter to Customization roughly outlining what all of the different addons are, by category, and why one might want them. -- John Weiss
Re: [rework docs] questions part two
On Sun, Jan 09, 2005 at 03:12:07PM +0100, Uwe Stöhr wrote: > I wrote: > > >The menu Navigate -> Refs seems to be broken. I expect that this menu > >let me jump from cross- and citation-reference to the next, but nothing > >happens. > > Sorry. The menu works., but it doesn't jump from reference to reference. > It jumps from one label to the next. So the menu name is a bit > confusing. It should better have the name "Label". And this is where your job as doc-editor comes in. ;) Describe that thang! -- John Weiss
Re: [rework docs] questions part two
On Mon, Jan 10, 2005 at 10:29:08PM +0100, Uwe Stöhr wrote: > > That I can copy a section with a section heading, keeping the format of > the heading. At the moment the format of sections headings are lost by > copy/cut and paste. I hope this now fixed now by Georg's patch (many > thanks for looking at this). Uwe: In M$ Word, formatting information is implicitly embedded just before the end of a line. In LyX, formatting information is implicitly embedded in-between the beginning of the line and the end of the previous line. I'm guessing that you're used to copying formatting using a "; S-; C-c". For LyX, retrain yourself to do "; S-; S-; C-c" (or, if you're using non-CUA bindings, replace the C-c with a M-w). If, however, I'm guessing wrong, and you are positioning the start of your region at the end of the previous line, or if mid-region section-headings lose their paragraph style, then this is indeedy-deed a bug introduced in v1.4CVS. -- John Weiss
Re: [rework docs] questions part one
On Sun, Jan 09, 2005 at 12:14:48PM +0100, Juergen Spitzmueller wrote: > I think gnu aspell has superceeded ispell for a lot of languages now, but > there might still be languages that are not supported well (or at all) by > aspell. In any case, it is good to have the choice. > > >In the preferences I can choose between aspell, ispell and hspell. > > But as personal dictionary I can only set an ispell one. Why? > > I think that (gnu) aspell does not use this option (it uses the personal > dictionary ~/.aspell..pws by default). This might as well count for > other spellchecker options. Don't know. Hmm... now that I read this, it makes me think that, perhaps, the details about the different flavors of spellchecker belong in Customization.lyx -- John Weiss
Re: [rework docs] reasons, plans, questions
On Sat, Jan 08, 2005 at 08:35:11PM +0100, Uwe Stöhr wrote: > > Reasons: > First I just wanted to update the documentation for LyX QT 1.3.x and > make a bit more platform independent. But while working on the > UserGuide, I realized that it is really out of date. The last complete > rework was done in 2000 for the LyX 1.0.x series. In the meantime many > updates and new sections were added. But the documentation still misses > many informations and doesn't follow a structured concept. Doesn't follow a strucutred concept, eh? Maybe you should read the mailling list archives before insulting me. > E.g. not all menus are described and there is no explanation for the > icon buttons under the menu bar. Ignoring the toolbar was a strategic move. Since tooltips will tell you what they do, it becomes obvious which menu items they're shortcuts for. If you don't know the corresponding menu item, then you clearly don't need it yet. Why are you wasting time messing around with arcane features? Get back to work on that document you're writing! ;) Not all of the menus are described because one doesn't need to know what they all are. One only needs to know where to find the features that one'll use most frequently while writing your average document. Again, a stragetic move, and one to give the docs a clearly-defined structure. I do agree, however, that 4 years of drift have rendered the documented menu locations of many features wrong. That certainly needs to be corrected. > Plans: > I would rework the Tutorial and the UserGuide. > The UserGuide would contain a section with an overview of all menus > and icon buttons. There is a chapter in the Reference manual for this. That is the logical place for it, as I said in the original description of the documents' strucutre. > But I want to delete platform specifig stuff like "Configuring the X > keyboard" etc. "Configuring the X keyboard" could probably go. Life on Linux & X has improved rather significantly in the 7 years since we added that. > and ironic comments. (These comments are often funny but > shouldn't be part of a manual.) ...because manuals should be as dry as dust, and so boring that nobody looks at them? > At last I want to merge the Customization and Extended manual. Some > of its stuff will be part of the UserGuide. Bad Idea. I suggest you look through the mailing list archives for my earlier emails where I describe the structure of the docs. These two files were split off for a reason. > I started once with a new layout for the UserGuide in koma-script book > format. ...because *everyone* is German and therefore uses a German-centric LaTeX class like koma-script. Uwe, if you are going to do this, and you want something that ALL of us can use, you need to start looking at the docs through the eyes of all of the users, not just from your own point of view. This is why I'm so critical. (While editor, I was equally critical of contributors for exactly the same reasons when they veered off course into their own narrow perspective.) Right now, I have doubts. I read a lot of high-flying ideas from you, with very little grounding in practicality. Let me give you an example of what I mean by "practicality": The "Customize the X keyboard for non-US-English". We added that because the lists were getting about 2-3 "Hlp Me" messages a month asking for this information. There was a practical reason for adding it to the docs, so in it went. There were practical reasons for the division of the docs. There were practical reasons for the names of the docs. I didn't personally agree with some of the names, but went with those changes, anyway, because my suggestions didn't convey the proper connotations to the wider audience of LyX users. As much as we'd all love to have someone, anyone, updating the docs, I have to play Lars here for a sec and ask: are you overdesigining? Do we really need this-or-that feature you want to add? And, in the case of the docs, can you put yourself and your own agenda (printable book) aside and make decisions grounded in practical, broad-user-community-consensus-based reasons? -- John Weiss
Re: [rework docs] questions part two
On Sun, Jan 09, 2005 at 12:56:11PM +0100, Georg Baum wrote: > Am Samstag, 8. Januar 2005 22:43 schrieb Uwe Stöhr: > > I want the example and template LyX files that comes with the beamer > > package to be added to LyX CVS. These files works very well and the > > author of course allows this. Is this possible or are there some > > objections? > > I don't think that it is worth the effort: I concur: 1. External LaTeX packages have no place in LyX. Lars/Asger/Jean-Marc and a cast-of-thousands worked long and hard to ensure we'd never need to do this (hence the whole LaTeX-Config engine & autogenerated manual). Why resurrect a long-rejected bad idea? 2. What the heck is a beamer? Just because you think it's the greatest-thing-since-sliced-bread doesn't mean everyone else does. Or even knows it exists. (Your bias is showing, Uwe!) If it were really all that critical (like e.g. geometry.sty), it'd already have integrated LyX support. If it's The Future, the devteam will discover it soon enough... -- John Weiss
Re: Creating a std::string from unsigned char[4097] ?
On Fri, Jan 07, 2005 at 05:18:23PM +0100, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Given this, which is MacOS X code to fill 'application_support': > > > | unsigned char application_support[PATH_MAX + 1]; > | OSStatus const status_code = > | FSRefMakePath(, application_support, PATH_MAX); > > > | what's the correct way to create a std::string? > > > | std::string(application_support) fails. > > Do you know its length? > >std::string(application_support, application_support + length); IIRC, there's a template member fn. std::string::assign() or std::string::insert() [I forget which] that takes a begin and end iterator. You could use that. For the end-iterator, just use (application_support + PATH_MAX). Afterward, just do a std::string::find_first_of() to search for the 1st '\0', then std::string::erase() from that point onward. Granted, it's not ideal, but it accomplishes what you want, and avoids the nasty reinterpret_cast<>()... -- John Weiss
Re: [rework docs] questions part one
On Sat, Jan 08, 2005 at 10:16:19PM +0100, Uwe Stöhr wrote: > > Spellchecker: > In the current version of the UserGuide I found a lot of > ispell-specific stuff that I would get rid of. Does the problems with > ispell described there still exist? Or does everybody replaced ispell by > the "newer and generally better aspell"? You are correct! Any mentions of ispell specifically should be replaced with more general text. You may want to occasionally make reference back to some initial section about spelling where you mention the different flavors of spellchecker out there and any subtleties that a user may have to pay attention to. May I suggest, once you know what your replacement prhases should be, doing a document-wide "Find 'ispell'" on every one of the manuals? Then, once you've finished all your edits, do the "Find 'ispell'" again to make sure you got them all. (This is the very same technique I used 7 years ago. Very good for such global doc-refactors.) -- John Weiss
Re: [rework docs] questions part two
On Sun, Jan 09, 2005 at 04:26:18PM +0100, Uwe Stöhr wrote: > Georg Baum wrote: > > >>As I use LyXWin, could somebody please send me his file > >>"LaTeX-Configuration"? This menu is broken in LyXWin and I need it to > >>describe it in the docs. Thanks. > > > >I guess you don't mean the file that you can get via Help->LaTeX > >Configuration? > > No I mean exactly this one. In case no one's sent you theirs, I'm attaching the one from the laptop. -- John Weiss #LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 221 \textclass article \language english \inputencoding default \fontscheme default \graphics dvips \paperfontsize 0 \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 2 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle plain \layout Title Inventory of your LaTeX configuration \layout Author Automatically generated by LyX (do not edit). \layout Date October 5, 2004 \layout Standard This file describes the different LaTeX add-ons that LyX can handle. Below you'll find six sections: \layout Enumerate Some basic details about your LaTeX installation. In particular, you should make sure that your version of LaTeX is recent enough. \layout Enumerate Some common fonts that LyX knows about. This is rather sparse at the moment. \layout Enumerate The document classes that should be standard on any LaTeX implementation. This section is only here for completeness. \layout Enumerate Some optional document classes that LyX knows about. If one of these is marked as missing (the \begin_inset Quotes eld \end_inset Found \begin_inset Quotes erd \end_inset item is no) and you need its functionality, you can grab it at your nearest CTAN ftp site \begin_inset Foot collapsed true \layout Standard The participating hosts in the Comprehensive TeX Archive Network are: \layout LyX-Code ftp://ftp.dante.de/tex-archive \layout LyX-Code ftp://ctan.tug.org/tex-archive \layout LyX-Code ftp://ftp.tex.ac.uk/tex-archive \layout Standard There are also a zillion mirror sites which are listed at the three primary sites. \end_inset at the location indicated in the \begin_inset Quotes eld \end_inset CTAN \begin_inset Quotes erd \end_inset item. Note that only detected document classes can be selected as document layouts in LyX. \layout Enumerate The packages that have been stamped \begin_inset Quotes eld \end_inset required \begin_inset Quotes erd \end_inset by the LaTeX maintainers. These ones should definitely be present, but you may not have some of them if your LaTeX distribution is a bit old. \layout Enumerate Some packages that LyX uses when you try to change the margins of your document. The detection of these items does not yet affect the options available inside LyX. \layout Enumerate Some common LaTeX packages that you might need with LyX, and you might also want to add to your LaTeX installation. The detection of these items does not yet affect the options available inside LyX. \layout Standard Note that most of these packages will be available if you use a modern TeX distribution such as teTeX. If you decide to install one of the missing items, you should tell LyX about it. After the installation, please use the menu entry \family sans \bar under O \bar default ptions\SpecialChar \menuseparator \bar under R \bar default econfigure \begin_inset Foot collapsed true \layout Standard or, if you want to change the system-wide settings, issue the command \family typewriter ./configure \family default from the LyX system directory (by default \family typewriter /usr/local/lib/lyx/ \family default ) \end_inset and reload this file to see if the new package was recognized. If the \begin_inset Quotes eld \end_inset Found \begin_inset Quotes erd \end_inset items read \begin_inset Quotes eld \end_inset ??? \begin_inset Quotes erd \end_inset , it means that LyX could not do the inventory of your LaTeX configuration for some reason. If you are using teTeX, it might be that the new package you installed is not found. This is because you forgot to run the command \family typewriter texhash \family default , which tells teTeX to update its own configuration. \layout Section LaTeX version currently in use \layout Standard The LaTeX version that LyX will use is: \family typewriter 2001/06/01 \family default . Note that, for best results, you should be using at least LaTeX release \family typewriter 1995/12/01 \family default \begin_inset Foot collapsed true \layout Standard In case it is not clear to you, this number is the date at which the version has been released. \end_inset . In fact, earlier versions may
Re: [rework docs] reasons, plans, questions
On Mon, Jan 10, 2005 at 09:41:56AM -0800, Jeremy C. Reed wrote: > > I though if the goal is to have a printed book, then the installation > should be covered also. Use a separate doc and include it via a master doc. Jeremy, Uwe, you guys are MAKING ME VERY NERVOUS with your near-fixation on making a printable version to the exclusion of everything else. One of the primary design constraints of the LyX Docs is that it be readable both in print and online. It serves both of these purposes. The LyX Developers even added a feature into LyX ... the infamous "menu arrow" special character ... to serve this very purpose. Ignore online readability/navigability at your peril! -- John Weiss
Language Lesson
On Sat, Jan 01, 2005 at 01:38:07PM +, Angus Leeming wrote: Ok, dokey. Lanuage Lesson for all international colleagues: The correct phrase is, Okey dokey. Or, if you prefer: Okee dokee Okey-dokey Okee-dokee Okie dokie Okie-dokie Ok, dokey is an affirmative reply to someone named, dokey. ;) -- John Weiss
Re: Latest LyX on Latest Cygwin
On Mon, Jan 03, 2005 at 01:08:32PM -0800, Kayvan A. Sylvan wrote: Hmmm... Yes, that can happen. I route around such problems though. For example: The Acrobat reader program needs dos paths. So, I use the following shell script (as /usr/local/bin/acroread): #!/bin/sh if [ $# -eq 1 ] then FILE=`cygpath -a -w $1` else FILE='' fi exec acroread.link $FILE This is the Canonically-Correct way of handling programs that require DOS pathnames while working under Cygwin programs. To whit: - You have some program that only knows DOS pathnames - You want to call said program from an interactive Cygwin shell, or from a Cygwin-based program. - So, you write something like this wrapper: #!/bin/sh CMD=/cygwin/abspath/to/the/real/program exe $CMD `cygpath -aw $@` Easy. So, for Cygwin, we can just provide these wrappers and call them by default instead. -- John Weiss
Language Lesson
On Sat, Jan 01, 2005 at 01:38:07PM +, Angus Leeming wrote: > Ok, dokey. Lanuage Lesson for all international colleagues: The correct phrase is, "Okey dokey". Or, if you prefer: "Okee dokee" "Okey-dokey" "Okee-dokee" "Okie dokie" "Okie-dokie" "Ok, dokey" is an affirmative reply to someone named, "dokey". ;) -- John Weiss
Re: Latest LyX on Latest Cygwin
On Mon, Jan 03, 2005 at 01:08:32PM -0800, Kayvan A. Sylvan wrote: > Hmmm... Yes, that can happen. I route around such problems though. > For example: The Acrobat reader program needs dos paths. So, I use > the following shell script (as /usr/local/bin/acroread): > > #!/bin/sh > > if [ $# -eq 1 ] > then > FILE=`cygpath -a -w "$1"` > else > FILE='' > fi > > exec acroread.link "$FILE" This is the Canonically-Correct way of handling programs that require DOS pathnames while working under Cygwin programs. To whit: - You have some program that only knows DOS pathnames - You want to call said program from an interactive Cygwin shell, or from a Cygwin-based program. - So, you write something like this wrapper: #!/bin/sh CMD="/cygwin/abspath/to/the/real/program" exe $CMD `cygpath -aw "$@"` Easy. So, for Cygwin, we can just provide these wrappers and call them by default instead. -- John Weiss
Re: license for documentation?
On Fri, Dec 17, 2004 at 11:35:02AM +0100, Asger Kunuk Ottar Alstrup wrote: On Tue, 14 Dec 2004, Jeremy C. Reed wrote: Does the COPYING file apply to all the doc/ documentation that don't have any license in them? For example, I don't see any republishing or reuse license for lib/doc/Customization.lyx. It is a good question. When the documentation was written, the concept of licenses for documentation was not really crystalised yet. So, the question was never really asked and thus never answered. I believe that a fair interpretation of intent is that the documentation is GPL. I want to test a print-on-demand service. I want to submit the LyX documentation in a single PDF format for a single book. Is this okay? I belive that would be ok, but you might try to ask John Weiss who is the main author of the documentation, and as such he would be the main copyright holder, In that case, I say that it's under the documentation-equivalent of the GPL. Why? Because waay back when I was editor-in-chief (like, 1996/97), I assumed that all of LyX, including docs, contributed templates, layouts, etc., would be under the GPL. And why did I read it like that? Because I took the license to apply to the entire sourcecode tarball. P.S.: The email address listed for me bounced because my old ISP died over 2 years ago. -- John Weiss
Re: license for documentation?
On Fri, Dec 17, 2004 at 11:35:02AM +0100, Asger Kunuk Ottar Alstrup wrote: > On Tue, 14 Dec 2004, Jeremy C. Reed wrote: > > > Does the COPYING file apply to all the doc/ documentation that > > don't have any license in them? > > > > For example, I don't see any republishing or reuse license for > > lib/doc/Customization.lyx. > > It is a good question. When the documentation was written, the concept of > licenses for documentation was not really crystalised yet. So, the > question was never really asked and thus never answered. I believe that a > fair interpretation of intent is that the documentation is GPL. > > > I want to test a print-on-demand service. I want to submit the LyX > > documentation in a single PDF format for a single book. Is this okay? > > I belive that would be ok, but you might try to ask John Weiss who is the > main author of the documentation, and as such he would be the main > copyright holder, In that case, I say that it's under the documentation-equivalent of the GPL. Why? Because waay back when I was editor-in-chief (like, 1996/97), I assumed that all of LyX, including docs, contributed templates, layouts, etc., would be under the GPL. And why did I read it like that? Because I took the license to apply to the entire sourcecode tarball. P.S.: The email address listed for me bounced because my old ISP died over 2 years ago. -- John Weiss
Re: [preliminary patch] moving XFig files
On Sat, Oct 30, 2004 at 01:48:47PM +, Andreas Vox wrote: Unfortunately it also resolves all contained file references relative to the directory of the symlink, not relative to the original file. So there's no real advantage to copying, Okay, then I'm confused and don't understand what it is you're doing. I was under the impression that the files in question weren't generated, but were pre-existing EPS files. I was also under the impression that you were moving everything to a temp-directory so that the resulting DVI files would contain only relative paths, not absolute ones. You can ignore my comments. BTW: While Windoze doesn't have native symlinks, it does have shortcuts. Additionally, with the Cygwin libraries, you can have symlinks under Windoze. They work only with the Cygwin programs, but that's a non-issue since (I assume) we need Cygwin for the Win-version of LyX. -- John Weiss
Re: [preliminary patch] moving XFig files
On Sat, Oct 30, 2004 at 01:48:47PM +, Andreas Vox wrote: > Unfortunately it also resolves all contained file references > relative to the directory of the symlink, not relative to the > original file. So there's no real advantage to copying, Okay, then I'm confused and don't understand what it is you're doing. I was under the impression that the files in question weren't generated, but were pre-existing EPS files. I was also under the impression that you were "moving" everything to a temp-directory so that the resulting DVI files would contain only relative paths, not absolute ones. You can ignore my comments. BTW: While Windoze doesn't have native symlinks, it does have shortcuts. Additionally, with the Cygwin libraries, you can have symlinks under Windoze. They work only with the Cygwin programs, but that's a non-issue since (I assume) we need Cygwin for the Win-version of LyX. -- John Weiss
