virus
I have modified the lyx-users and lyx-devel lists's configuration, so that they accept messages only from subscribers. This is only temporarily, and I will change the config back if I do not see any more of these "viral" messages coming at our server. If a nonsubscriber posts, she will get a bounce explaining the situation. Mate
lyx-1.1.5fixcvs RPMs are ready
Hi folk, The latest lyx-1.1.5fixcvs RPMs and tarball are now ready at ftp://ftp.sylvan.com/pub/lyx/devel/lyx-1.1.5/ Check these out and report poblems to the list. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
subscribers only?
As a countermeasure, should I temporarily set up the users and devel lists subscribers only until the messages with Subject: Re: [phxjug-java] Re: Two tools stop coming in? Or just use a filter? Mate
[PATH] www-devel GUI-I Porting Matrix
This is a first stab at a porting matrix page. It's pretty simple to update. I surely haven't got *all* the dialogs however, and some of the entries could do with clearer names. comments ? thanks john 2000-09-11 John Levon <[EMAIL PROTECTED]> * start.php3 * index.php3 * guii.php3: Include GUI independence progress table -- "True communication is possible only between equals, because inferiors are more consistently rewarded for telling their superiors pleasant lies than for telling the truth." portingmatrix.tar.gz
Re: GUIRuntime init ?
Juergen, Gnome implementation has a tiny bug: the strings app_id and app_version should be static too due to a "feature" of Gnome--. Marko
Re: New export code
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> Here is a patch that solves this problem (and others). Jean-Marc> I'll apply it. BTW, Dekel, there seem to be code (in filetool.C and the use of QuitLyX) that seems interesting for 1.1.5fix too. Do you think you could make a patch out of it? Also, I'd be interested by the patch you submitted some times ago to reduce excessive repainting when using backspace. JMarc
Re: New export code
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> Here is a patch that solves this problem (and others). I'll apply it. JMarc
RE: GUIRuntime init ?
On 09-Sep-2000 John Levon wrote: > > This seems the nicest solution (?). Alternatively a static init() method > could be added to GUIRunTime ? > Done! And tested for xforms, kde AND gnome :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ FORTRAN is a good example of a language which is easier to parse using ad hoc techniques. -- D. Gries [What's good about it? Ed.]
(Dekel) Quoting $$FName in converter.C
Dekel, Concerning the changes you did in Converter::setViewer() to quote $$FName. I do not think these changes were needed. The best is probably to use QuoteName() on the file name later, as in: string command2 = subst(command, "$$FName", QuoteName(OnlyFilename(filename))); The advantage of QuoteName is that it does nothing for OS/2 (where 'quoting' is not well understood by the shell) and could be adapted later to provide a better quoting mechanism. JMarc
[PATCH] KDE TOC,Citation,Index Forms, small Url cleanup
Please consider thanks john 2000-09-11 John Levon <[EMAIL PROTECTED]> * src/frontends/kde/formurldialog.C * src/frontends/kde/formurldialog.h * src/frontends/kde/FormUrl.C * src/frontends/kde/FormUrl.h: minor cleanups * src/frontends/kde/QtLyXView: wrapper to avoid Qt namespace mangling * src/frontends/kde/Makefile.am * src/frontends/kde/FormToc.C * src/frontends/kde/FormToc.h * src/frontends/kde/FormCitation.C * src/frontends/kde/FormCitation.h * src/frontends/kde/FormIndex.C * src/frontends/kde/FormIndex.h * src/frontends/kde/formtocdialog.C * src/frontends/kde/formtocdialog.h * src/frontends/kde/formcitationdialog.C * src/frontends/kde/formcitationdialog.h * src/frontends/kde/formindexdialog.C * src/frontends/kde/formindexdialog.h: new Toc,Citation,Index dialogs toccitindex.tar.gz
Re: I'm back, take 2 :)
jmarc jmentioned,
> > "hawk" == hawk <[EMAIL PROTECTED]> writes:
> hawk> 2) I had a builid on a fresh install of debian that supposedly
> hawk> had never had a lyx before. nonetheless, without using --prefix,
> hawk> it didn't land in /usr/local, but somewhere weird like
> hawk> /usr/x11/bin
> Obvious question: do you have a /usr/X11/bin/lyx?
At the moment, no :) I did end up removing one, and this is apparently
where debian puts it now (which I don't believe was teh case in the
past). I suspect something weird happened during debian installation or
update, or oen of my bizzare network problems (which began when a
genius pulled my network cable out because "unix is a security threat"
[note: all machines here have outlook, netscape, and ofice, with
*everything* enabled!).
I had to remove *three* copies of lyx while trying to clean up: debian
put one in (I still don't know why :), I compiled one, and there was a
third one . . .
> hawk> 4) the biggy. I seem to have lost a great many bindings with the
> hawk> fresh cvs this week. The one I built a month or so ago didn't
> hawk> have the problem as badly (or maybe I didn't try as much). e.g.,
> hawk> meta-M { no longer gives me braces, and when I do them from the
> hawk> math panel, no shortcut appears on the screen.
> It is dues to the fact that M-m now opens the math menu. Lars does not
> want to have M-m bindings which are not real menu bindings. I'd be
> surprised if people like it %-]
err, err, my fingers . . . how do I retrain them? :) It took me over
ten years to get bits of word star out of them (and now that I've
mentioned this, I'll probably try to ^e my way up the screen for weeks
. . .).
We *are* going to have bindings, aren't we, even if they're not the
same? Being able to do it all from the keyboard is a big selling
point, and a major advantage over that evil equation editor in a
certain product . . . ALso, having significantly less keystrokes than
raw latex helps . . .
hawk
--
Re: OK Apply don't work in Document layout!
On 11-Sep-2000 Allan Rae wrote: > > Maybe the document is readonly? Maybe you have some invalid input field? > (but you print a warning if there is one so I'm sure you wouldn't have > missed that :Þ) > I should have a warning the problem is that 0cm is valid entry but vspace.C thinks it is not, I fixed this ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "What do you do when your real life exceeds your wildest fantasies?" "You keep it to yourself." -- Broadcast News
Re: [Lyx-feedback] Feedback from www.lyx.org
> "bellot" == bellot <[EMAIL PROTECTED]> writes:
bellot> I think I have found a strange bug. I can\'t use space or
bellot> accentuated characters (I use LyX to write french texts) in
bellot> the file names !
bellot> Every time I put a space in the file name or in a directory
bellot> name, I have an error at compilation time : \"Latex: missing
bellot> \\begin{document}\"
bellot> Actually, I use _ for space and non-accentuated characters in
bellot> directories and files names.
What version of LyX are you using?
JMarc
If it is broken, fix it (status update #1)
Hello, Since 1.1.6 is not here yet, a 1.1.5fix2 version might be useful. Let me recall that all these fixes have been checked in the branch lyx-1_1_5, which you can get with the command cvs checkout -d lyx-1_1_5 -r lyx-1_1_5 lyx-devel I advise those of you who want the 1.1.5 series to stabilize rapidly to check out this branch and try it out. As far as I know, it cannot be worse than 1.1.5fix1, anyway. In order to speed up a bit the release work on fix2, here is a small status document showing what has been done, and what has to be done. JMarc What's new == ** Bugfixes - fix display problems with math macros - fix error box positionning with math macros - add missing \protect around fragile math decorations - fix czech keymap - fix crash when copying bibiography insets - fix parsing of \set_color arguments in lyxrc - update sciword.bind - remove description of pdf support on lyxrc.example, since this does not work yet. ** Other: documentation update, UI translation updates (translators, please send me updated po files for 1.1.5!) Remaining problems == These are bugs which are probably small, and mostly appeared recently. Good clients for a fix release. Note that they exist in 1.1.6 too, so we'll have to fix them eventually. Please send me references to the ones I forgot. - clipboard-related crashes http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13754.html http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13712.html http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13338.html - we should check when writing to a stream failed due to not enough disk space (how?) http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13483.html http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg12733.html - crash when changing layout http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg13171.html - sometimes workAreaButtonRelease is called with button == 0 (this has already been discussed, but not fixed as far as I know) http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg12987.html - When the cursor is between two spaces, then the Shift-Cursor selection keys will lead to a mangled selection (on screen) http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg12431.html - the documentation should be reviewed to indicate the 1.1.5fix2 is a stable release (should some english-speaking volunteer have a look?). - mangled minibuffer after resizing the main window. I can't find a reference, but the effect is obvious (and recent). Could it be a consequence of Lars' recent changes to scrollbars? Or simply a flaw of the WorkArea? More generally, the minibuffer is strange since when you click in it, the text does not disappear. - bad karma between \noindent and Description http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg11759.html
Re: cannot compile on dec with gcc 2.95
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> so if you compile with --with-included-string everyting works Lars> ok? Lars> It seems tat your assempler cannot handle the long mangled names Lars> that are the rult of mangling C++ templates and library Lars> components. Indeed. It works fine with --with-included-strings. JMarc
Re: 3 bugs in lyx-1.1.5fix1
> "Ben" == Ben <[EMAIL PROTECTED]> writes: Ben> Third bug : Lyx's crash : create a new file from the template Ben> "slides" without saving it. Then change the class of the document Ben> to seminar. Answer yes, click on OK, answer abort, and lyx Ben> crashes. The output of the backtrace obtained with gdb is Ben> included in the file named "lyx_crash_backtrace.gz". Upgrade your xforms library to one compiled for glibc2.1. The one you use is compiled for an older version. JMarc
Re: Comments & Notes in LyX
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I think that we are going to remove the note inset and the Lars> comment paragraph layout, and replace them with a comment inset. Lars> This comment will be exported to the latex file as well. Lars> (usually as a comment envir) Why not with good old "%"? I do not see the need for the comment environment to write "remember to re-read this section later" or some other stuff notes are for. This should be configurable in some way (two sorts of comments?). There could also be a choice for not outputing at all. JMarc
Re: I'm back, take 2 :)
> "hawk" == hawk <[EMAIL PROTECTED]> writes:
hawk> 2) I had a builid on a fresh install of debian that supposedly
hawk> had never had a lyx before. nonetheless, without using --prefix,
hawk> it didn't land in /usr/local, but somewhere weird like
hawk> /usr/x11/bin
Obvious question: do you have a /usr/X11/bin/lyx?
hawk> 4) the biggy. I seem to have lost a great many bindings with the
hawk> fresh cvs this week. The one I built a month or so ago didn't
hawk> have the problem as badly (or maybe I didn't try as much). e.g.,
hawk> meta-M { no longer gives me braces, and when I do them from the
hawk> math panel, no shortcut appears on the screen.
It is dues to the fact that M-m now opens the math menu. Lars does not
want to have M-m bindings which are not real menu bindings. I'd be
surprised if people like it %-]
JMarc
Re: Lyx 1.1.5fix1 and pdflatex
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> These were added by Lars but no corresponding code exists to Allan> use them :( It may be nearly ready by 1.1.6 but I'm not sure Allan> what Dekel has done with his new export code. Allan> JMarc maybe you should remove those entries from 1.1.5fix? and Allan> this would help avoid a little of this confusion. Good idea. I just did it. JMarc
Re: LyX review
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes: Amir> http://www.showmelinux.com/092000/inreview.html Hmm, better than the appreciation given i nthe first paragraph of http://linux.com/desktops/newsitem.phtml?sid=91&aid=10740 I've already read that LyX is ugly, but arcane... JMarc
Re: InsetRef suggestion: comments please
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: Marko> The problem is whether menus and toolbars should have their own Marko> means to track the state of LyX actions or there should be some Marko> general way to inform about the change of the status to all Marko> interested parties. At present, we have to check the status of Marko> each lyxfunc used in the menus and toolbars during update. I Marko> think that this leads to duplicated code and to unnecessary CPU Marko> load. Do you have evidence that the calls to LyXFunc::getStatus() have a high cost? I think that having checks all over LyX code (Oh, we just changed the font! let's tell the menu about that) would have a high readability cost on the kernel code. Of course, if a profiler shows that getStatus is very expensive... Also, what kind of duplicated code are you thinking about? My first idea when designing this code was to have an abstract interface for the different frontends (with add() calls and things like that), but Asger somehow convinced me that with some GUI toolkits it is not possible to add an entries to a menu one by one (now I believe he was just drunk, but the code is written). Marko> Every time when some state is Marko> changed this machine will notify all GUI elements (menu, Marko> toolbar, status bar, programs connected through lyxserver) Anyway, you will have to scan the menu to see what element is interested in bold setting, won't you? Marko> distributing a signal to all interested parties with exact Marko> description of the change (for example, title of section 3.1 is Marko> changed). I guess you are interested in this one for the TOC menu. I admit that having the TOC menu in a tearable menu (and unfortunately many people will want to do that) will be a big problems (exactly for the same reason why the TOC popup does not refresh automatically). What I'd do for now is have an "update" entry on top of TOC menu entries, like for the TOC popup. It is a bit ugly, but it should work... JMarc
Re: InsetRef suggestion: comments please
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> You could start by grouping checks -- various menu entries Allan> aren't available for readonly docs, different menu entries are Allan> available when no buffers exist. That sort of thing. Then you Allan> can deactivate a bunch of stuff based on the LyXFunc status (or Allan> was that a LyXAction enum I can't remember). Have you ever read LyXFunc::getStatus()? It does exactly that, if I understand you correctly. Allan> I'll try to look at the menu code but I'm thinking it Allan> could/should be handled via the Dialogs (just like another Allan> dialog -- we've had this arguement before so don't tell me Allan> toolbars aren't dialogs. I've heard it all before. We just Allan> reuse the same abstraction (show, hide, update)). Yes, it is (as I already mentionned) certainly possible to use signals to at least connect GUI-I menus to their frontends. This would certainly be cleaner than using a Pimpl. However, I doubt it would be worth bending their semantics to fit the Dialogs framework... We could maybe have a common framework for toolbars and menus, though. JMarc
Re: InsetRef suggestion: comments please
On Fri, 8 Sep 2000, Marko Vendelin wrote: > > > On 8 Sep 2000, Jean-Marc Lasgouttes wrote: > > > Let's face it: if you want to a tearable menu to change when the > > cursor moves you will have to do _something_. What I would try to do > > if I were to write the gnome frontend is first to build the menus at > > update() time and see whether it causes performance problems. If it is > > the case (and it might be), I would create the menus in set(), cache > > the status of each lyxfunc used and, at update() time, change the > > state of the entries of the existing menu (like for the toolbar) on a > > case by case basis. For OptItems, one would have to insert/delete > > entries in the existing menu (which should be possible). And with a > > bit of double buffering, this should work well enough. > > The problem is whether menus and toolbars should have their own means to > track the state of LyX actions or there should be some general way to > inform about the change of the status to all interested parties. At > present, we have to check the status of each lyxfunc used in the menus and > toolbars during update. I think that this leads to duplicated code and to > unnecessary CPU load. You could start by grouping checks -- various menu entries aren't available for readonly docs, different menu entries are available when no buffers exist. That sort of thing. Then you can deactivate a bunch of stuff based on the LyXFunc status (or was that a LyXAction enum I can't remember). > The other solution is to implement some kind of state machine which will > completely describe the current state of LyX (which documents are open, > cursor positions, TOC, LOF, LOT, LOA, bold on/off, emphasize on/off, ...). That sounds like a terribly large and hideously ugly state machine. The mother of all state machines? > Every time when some state is changed this machine will notify all GUI > elements (menu, toolbar, status bar, programs connected through lyxserver) > by distributing a signal to all interested parties with exact description > of the change (for example, title of section 3.1 is changed). I think this > solution should lead to faster and cleaner code, but maybe I am wrong... If you're going to distribute info like "title of section 3.1 has changed" you are passing the wrong info -- or at least the wrong detail. Pass "the current character attributes have changed" and "the current paragraph attributes have changed" instead. In fact it would be possible to edit the section3.1 heading and not generate either of these signals since there would be no new info if you didn't change the attributes of the text. What I was envisioning (and I'm sure it's even mentioned in the gui-indep doc which I still have to update) is that we have character and paragraph based callbacks. These would be similar to the Dialogs::updateBufferDependent signal except at character and paragraph scope. We could make something like: Signal1 updateCharacter; That way anything that wants to know what the current characters attributes are will connect to the signal and will get that info sent to them when it changes (this means sprinkling activations of the signal around the source). For paragraphs, we could just send out what the current paragraph style is. There may not be much else generally needed -- or just send a copy of the ParaParams struct since that seesm to have everything in it. Paragraphs will affect menus. Characters might affect menus (c-s menus that included bold/emphasize etc. would be affected -- however since you can't open a menu and move the cursor at the same time you would be better off checking this explicitly (okay, tearoffs need signals, but regular menus don't)) -- toolbars would be affected if they had bold etc. buttons on them. > The second advantage is that we can store the state of this machine during > GNOME (KDE) logout and load it during login. Maybe something like this is > implemented in LyX already and I just don't know anything about it or it > has been discussed and rejected already. If true then sorry for spam. You can instead store the current documents name and current cursor position and get it all at startup when the document is reloaded. I'll try to look at the menu code but I'm thinking it could/should be handled via the Dialogs (just like another dialog -- we've had this arguement before so don't tell me toolbars aren't dialogs. I've heard it all before. We just reuse the same abstraction (show, hide, update)). Allan. (ARRae)
Re: Lyx 1.1.5fix1 and pdflatex
On Fri, 8 Sep 2000, Michael Schmitt wrote: > Hello, > > I would like to use lyx with pdflatex. > > There exist a lot of settings in file 'lyxrc' but they do not work as > expected. Moreover, nothing is said in the documentation about creating > pdf files. Has anybody ever tried to do so? PDF file are very popular > nowadays and Lyx should definitely support them. These were added by Lars but no corresponding code exists to use them :( It may be nearly ready by 1.1.6 but I'm not sure what Dekel has done with his new export code. JMarc maybe you should remove those entries from 1.1.5fix? and this would help avoid a little of this confusion. Allan. (ARRae)
Re: I'm back, take 2 :)
On 8 Sep 2000, Lars Gullik Bjønnes wrote: > hawk <[EMAIL PROTECTED]> writes: > | 3) In the preferences dialog, when I click on "show banner" (I presume > | this disables the sticky splash screen? I hate splash screens; under > | fvwm they take over that region of screen until the program is ready), > | "Restore" becomes selectable, but "Save" and "Apply" do not. I assume > | this is incorrect, and to get back up to speed, I'll try to peek at the > | code next week. > > Please do, some of this code is pretty new and untested. I've checked this here and don't see this. The only way for this to happen is if you have an invalid entry in either of the Paths tab entries or an invalid size entry for the Scrren Fonts tab (tiny, script entries). I'll have to check whether Preferences tests validity when first opened or if I test after only after input. So it's not quite incorrect behaviour, since you do have an invalid entry somewhere, but I suspect it'll be due to the setting of your Paths->Template Dir. entry (since I had something similar weeks ago). Allan. (ARRae)
Re: OK Apply don't work in Document layout!
On Fri, 8 Sep 2000, Juergen Vigna wrote: > Hi! > > After some of the last changes in ButtonPolicies the OK and Apply button > does not activate itself anymore in the DocumentLayout! > > Allan do you know why? Maybe the document is readonly? Maybe you have some invalid input field? (but you print a warning if there is one so I'm sure you wouldn't have missed that :Þ) Any particular document or all documents? I haven't seen this yet and I'm using current cvs (well a couple days back anyway) for writing papers. Allan. (ARRae)
