Re: I'm back, take 2 :)
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| "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.
This is also an artifact of the new menu code. It is not LyX that
open the menus anymore, it is XForms. (a lot saner imho)
| Lars does not
| want to have M-m bindings which are not real menu bindings. I'd be
| surprised if people like it %-]
What is the problem with changing it to "C-m {"?
Lgb
Re: Comments Notes in LyX
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | "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. Why? (some internal comments that should not go to the general public?) Currently we have both a comment paragraph layout and a note inset, I am not sure that we need both. Lgb
[PATCH] KDE FormToc cleanup
2000-09-13 John Levon [EMAIL PROTECTED]
* src/frontends/kde/formtocdialog.C
* src/frontends/kde/formtocdialog.h
* src/frontends/kde/FormToc.C
* src/frontends/kde/FormToc.h: change to
make TOC hierarchical properly
? formtoc.diff
Index: FormToc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/kde/FormToc.C,v
retrieving revision 1.1
diff -u -r1.1 FormToc.C
--- FormToc.C 2000/09/12 15:13:18 1.1
+++ FormToc.C 2000/09/13 06:35:32
@@ -15,6 +15,8 @@
#include config.h
+#include stack
+
#include "formtocdialog.h"
#include "Dialogs.h"
@@ -28,6 +30,7 @@
using std::vector;
using std::pair;
+using std::stack;
FormToc::FormToc(LyXView *v, Dialogs *d)
: dialog_(0), lv_(v), d_(d), inset_(0), h_(0), u_(0), ih_(0),
@@ -92,18 +95,59 @@
toclist = tmp[type];
dialog_-tree-clear();
+
+ dialog_-tree-setUpdatesEnabled(false);
-
- // FIXME: should do hierarchically. at each point we need to know
- // id of item we've just inserted, id of most recent sibling, and
- // id of parent
+ int depth = 0;
+ stack pair QListViewItem *, QListViewItem * istack;
+ QListViewItem *last = 0;
+ QListViewItem *parent = 0;
+ QListViewItem *item;
+
+ // Yes, it is this ugly. Two reasons - root items must have a QListView
+parent,
+ // rather than QListViewItem; and the TOC can move in and out an arbitrary
+number
+ // of levels
- dialog_-tree-setAutoUpdate(false);
for (vector Buffer::TocItem ::const_iterator iter = toclist.begin();
iter != toclist.end(); ++iter) {
- dialog_-tree-insertItem((string(4*(*iter).depth,'
')+(*iter).str).c_str(), 0, -1, false);
+ if (iter-depth == depth) {
+ // insert it after the last one we processed
+ if (!parent)
+ item = (last) ? (new
+QListViewItem(dialog_-tree,last)) : (new QListViewItem(dialog_-tree));
+ else
+ item = (last) ? (new QListViewItem(parent,last)) :
+(new QListViewItem(parent));
+ } else if (iter-depth depth) {
+ int diff = iter-depth - depth;
+ // first save old parent and last
+ while (diff--)
+ istack.push(pair QListViewItem *, QListViewItem *
+(parent,last));
+ item = (last) ? (new QListViewItem(last)) : (new
+QListViewItem(dialog_-tree));
+ parent = last;
+ } else {
+ int diff = depth - iter-depth;
+ pair QListViewItem *, QListViewItem * top;
+ // restore context
+ while (diff--) {
+ top = istack.top();
+ istack.pop();
+ }
+ parent = top.first;
+ last = top.second;
+ // insert it after the last one we processed
+ if (!parent)
+ item = (last) ? (new
+QListViewItem(dialog_-tree,last)) : (new QListViewItem(dialog_-tree));
+ else
+ item = (last) ? (new QListViewItem(parent,last)) :
+(new QListViewItem(parent));
+ }
+ lyxerr[Debug::GUI] "Table of contents" endl "Added item "
+iter-str.c_str()
+" at depth " iter-depth ", previous sibling \""
+(last ? last-text(0) : "0")
+"\", parent \"" (parent ? parent-text(0) : "0") "\""
+ endl;
+ item-setText(0,iter-str.c_str());
+ depth = iter-depth;
+ last = item;
}
- dialog_-tree-setAutoUpdate(true);
+
+ dialog_-tree-setUpdatesEnabled(true);
dialog_-tree-update();
}
@@ -113,15 +157,19 @@
switch (type) {
case Buffer::TOC_TOC:
dialog_-setCaption(_("Table of Contents"));
+ dialog_-tree-setColumnText(0,_("Table of Contents"));
break;
case Buffer::TOC_LOF:
dialog_-setCaption(_("List of Figures"));
+ dialog_-tree-setColumnText(0,_("List of Figures"));
break;
case Buffer::TOC_LOT:
dialog_-setCaption(_("List of Tables"));
+ dialog_-tree-setColumnText(0,_("List of Tables"));
break;
case Buffer::TOC_LOA:
dialog_-setCaption(_("List of Algorithms"));
+
Re: dotfill,hrulefill status open behavior
"Garst R. Reese" [EMAIL PROTECTED] writes: | I'll start with the open behavior. | I click open and give a new file name. LyX asks if it wants to create | the new file and I answer yes. I later try to save the file and it asks | for a file name. | I enter the same file name that I entered before. LyX saves the file in | /home/garst instead of /home/garst/lyxdocs which is specifed in my | lyxrc. Is this your code playing tricks on us Jürgen? Or it is something older/else? | I think Lars was working on adding dotfill and hrulefill to the insert | special character menu. I looked at it... but it really involves a bit more than just the menu... Lgb
Re: [PATCH] Fix KDE Citation thinko
John Levon [EMAIL PROTECTED] writes: | On Tue, 12 Sep 2000, John Levon wrote: | | | Doh ! | | (There also seems to a problem with FormToc - namely the list-of-figures | from getTocList seems to empty, even when it shouldn't be. Can someone | double check it works for xforms/kde, because my older CVS at home doesn't | seem to have this problem ... | | | In fact turning off NEW_INSETS, I don't see a problem, it works fine. Lars | ? Or is this not supposed to be working yet ? NEW_INSETS are supposed to be working (in almost all cases), so it it doesn't you have found a bug. Please help to fix it. Lgb
Re: [PATCH] Fix KDE Citation thinko
On 13 Sep 2000, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Tue, 12 Sep 2000, John Levon wrote: | | | Doh ! | | (There also seems to a problem with FormToc - namely the list-of-figures | from getTocList seems to empty, even when it shouldn't be. Can someone | double check it works for xforms/kde, because my older CVS at home doesn't | seem to have this problem ... | | | In fact turning off NEW_INSETS, I don't see a problem, it works fine. Lars | ? Or is this not supposed to be working yet ? NEW_INSETS are supposed to be working (in almost all cases), so it it doesn't you have found a bug. Please help to fix it. Lgb Of course ! I'll have a look now. FWIW I seem to remember from yesterday that the TOC_LOF part of toclist was empty from the getTocList() point of view. TOC_TOC worked fine, I didn't test the others. thanks john -- "I bet the human brain is a kludge." - Marvin Minsky
Re: lyx-1.1.5fix1 port to OpenBSD
Benjamin Karas [EMAIL PROTECTED] writes: | Hello, | | I'm working on a port of lyx-1.1.5fix1 to OpenBSD. Everything compiled | fine, but two Makefiles gave me some trouble doing a fake install. I've | attached patches for po/Makefile.in.in and intl/Makefile.in. The changes | shouldn't break anything. | | I'm reusing the old DESC and COMMENT files. I think they should be | updated, but I'm not sure what a good description would be. Here are the | old ones: | | --( COMMENT )-- | graphical frontend for LaTeX (Almost WYSIWYG) | --*-*-- | | --( DESC )-- | LyX is a wordprocessor frontend to LaTeX, which gives both the | ease-of-use of a wordprocessor, and the flexibility and power of | LaTeX. | | Quasi-WYSIWYG interface, many LaTeX styles and layouts automatically | generated. Speeds up learning LaTeX and makes complicated layouts | easy and intuitive. New features include spell-checking, international | character support, WYSIWYG graphics, tables, and equations. | | Author: [EMAIL PROTECTED] (Matthias | Ettrich) Autor: The LyX Team ([EMAIL PROTECTED]) | Maintained-by: [EMAIL PROTECTED] (David L. Johnson) Maintained-by: [EMAIL PROTECTED] (Lars Gullik Bjønnes) and the LyX Team ([EMAIL PROTECTED]) | --*-*-- | | I'll be submitting this to the OpenBSD port maintainers in a day or two | and will incorporate any suggestions you have. | | Thanks. | | Benjamin Karas | [EMAIL PROTECTED] | Tippit 430E; 216.754.2004 | | --- po/Makefile.in.in.origTue Sep 12 18:57:02 2000 | +++ po/Makefile.in.in Tue Sep 12 18:51:04 2000 | @@ -24,6 +24,8 @@ gnulocaledir = $(prefix)/share/locale | gettextsrcdir = $(prefix)/share/gettext/po | subdir = po | | +DESTDIR = | + Why isn't --prefix enough for you? Anyway if this is a general problem with the Makefile.in.in in the gettext, a report should be submitted to the gettex maintainers. Lgb
Re: Comments Notes in LyX
Allan Rae [EMAIL PROTECTED] writes: | On 13 Sep 2000, Lars Gullik Bjønnes wrote: | | Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | | | "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. | | Why? (some internal comments that should not go to the general | public?) | | Currently we have both a comment paragraph layout and a note inset, I | am not sure that we need both. | | You may recall the request a week or so ago for a glorified version of | notes to assist in editting -- the notes are a great feature (especially | the bold yellow label) and the request asked for better navigation between | notes (I forget what name they suggested). | | Notes for editting/proofreading are different to comments. I'd like a | full support for the comment environment so we don't change paragraph | styles when we make something a comment. But I want/need editting notes | also -- as do others. | | Both styles of "comments" should be supported imo (both as collapsible | insets so we can eradicate another dialog). Very well, expect that in 1.2.0 then. NEW_INSETS should be enabled for this. Lgb
Re: [PATCH] KDE FormToc cleanup
Argh, I accidentally sent an old version which won't compile.
Sorry ! New one attached
I should get some sleep :/
thanks
john
On Wed, 13 Sep 2000, John Levon wrote:
2000-09-13 John Levon [EMAIL PROTECTED]
* src/frontends/kde/formtocdialog.C
* src/frontends/kde/formtocdialog.h
* src/frontends/kde/FormToc.C
* src/frontends/kde/FormToc.h: change to
make TOC hierarchical properly
? a
? formtoc.diff
Index: FormToc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/kde/FormToc.C,v
retrieving revision 1.1
diff -u -r1.1 FormToc.C
--- FormToc.C 2000/09/12 15:13:18 1.1
+++ FormToc.C 2000/09/13 07:05:21
@@ -15,6 +15,8 @@
#include config.h
+#include stack
+
#include "formtocdialog.h"
#include "Dialogs.h"
@@ -28,6 +30,7 @@
using std::vector;
using std::pair;
+using std::stack;
FormToc::FormToc(LyXView *v, Dialogs *d)
: dialog_(0), lv_(v), d_(d), inset_(0), h_(0), u_(0), ih_(0),
@@ -92,18 +95,59 @@
toclist = tmp[type];
dialog_-tree-clear();
+
+ dialog_-tree-setUpdatesEnabled(false);
-
- // FIXME: should do hierarchically. at each point we need to know
- // id of item we've just inserted, id of most recent sibling, and
- // id of parent
+ int depth = 0;
+ stack pair QListViewItem *, QListViewItem * istack;
+ QListViewItem *last = 0;
+ QListViewItem *parent = 0;
+ QListViewItem *item;
+
+ // Yes, it is this ugly. Two reasons - root items must have a QListView
+parent,
+ // rather than QListViewItem; and the TOC can move in and out an arbitrary
+number
+ // of levels
- dialog_-tree-setAutoUpdate(false);
for (vector Buffer::TocItem ::const_iterator iter = toclist.begin();
iter != toclist.end(); ++iter) {
- dialog_-tree-insertItem((string(4*(*iter).depth,'
')+(*iter).str).c_str(), 0, -1, false);
+ if (iter-depth == depth) {
+ // insert it after the last one we processed
+ if (!parent)
+ item = (last) ? (new
+QListViewItem(dialog_-tree,last)) : (new QListViewItem(dialog_-tree));
+ else
+ item = (last) ? (new QListViewItem(parent,last)) :
+(new QListViewItem(parent));
+ } else if (iter-depth depth) {
+ int diff = iter-depth - depth;
+ // first save old parent and last
+ while (diff--)
+ istack.push(pair QListViewItem *, QListViewItem *
+(parent,last));
+ item = (last) ? (new QListViewItem(last)) : (new
+QListViewItem(dialog_-tree));
+ parent = last;
+ } else {
+ int diff = depth - iter-depth;
+ pair QListViewItem *, QListViewItem * top;
+ // restore context
+ while (diff--) {
+ top = istack.top();
+ istack.pop();
+ }
+ parent = top.first;
+ last = top.second;
+ // insert it after the last one we processed
+ if (!parent)
+ item = (last) ? (new
+QListViewItem(dialog_-tree,last)) : (new QListViewItem(dialog_-tree));
+ else
+ item = (last) ? (new QListViewItem(parent,last)) :
+(new QListViewItem(parent));
+ }
+ lyxerr[Debug::GUI] "Table of contents" endl "Added item "
+iter-str.c_str()
+" at depth " iter-depth ", previous sibling \""
+(last ? last-text(0) : "0")
+"\", parent \"" (parent ? parent-text(0) : "0") "\""
+ endl;
+ item-setText(0,iter-str.c_str());
+ depth = iter-depth;
+ last = item;
}
- dialog_-tree-setAutoUpdate(true);
+
+ dialog_-tree-setUpdatesEnabled(true);
dialog_-tree-update();
}
@@ -113,15 +157,19 @@
switch (type) {
case Buffer::TOC_TOC:
dialog_-setCaption(_("Table of Contents"));
+ dialog_-tree-setColumnText(0,_("Table of Contents"));
break;
case Buffer::TOC_LOF:
dialog_-setCaption(_("List of Figures"));
+ dialog_-tree-setColumnText(0,_("List of Figures"));
break;
case Buffer::TOC_LOT:
dialog_-setCaption(_("List of Tables"));
+
NEW_INSETS (was Re: [PATCH] Fix KDE Citation thinko)
On 13 Sep 2000, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Tue, 12 Sep 2000, John Levon wrote: | | | Doh ! | | (There also seems to a problem with FormToc - namely the list-of-figures | from getTocList seems to empty, even when it shouldn't be. Can someone | double check it works for xforms/kde, because my older CVS at home doesn't | seem to have this problem ... | | | In fact turning off NEW_INSETS, I don't see a problem, it works fine. Lars | ? Or is this not supposed to be working yet ? NEW_INSETS are supposed to be working (in almost all cases), so it it doesn't you have found a bug. Please help to fix it. Lgb Lars, the toclist is indeed empty, but I must be being stupid, because the only code I can find that fills up any of these on a getTocList() is Buffer::getTocList() in buffer.C, and with defined NEW_INSETS defined, the only thing that gets added to the list is via line 3751 : l[TOC_TOC].push_back(tmp); So l[TOC_LOF] et al are never filled What am I missing ? thanks john -- "I bet the human brain is a kludge." - Marvin Minsky
Re: dotfill,hrulefill status open behavior
On 13-Sep-2000 Lars Gullik Bjønnes wrote: Is this your code playing tricks on us Jürgen? Or it is something older/else? I guess this is my code playing tricks :), I will have a look and fix it! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Peace, n.: In international affairs, a period of cheating between two periods of fighting. -- Ambrose Bierce, "The Devil's Dictionary"
Re: InsetRef suggestion: comments please
On 11 Sep 2000, Jean-Marc Lasgouttes wrote: "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). I was in fact referring the possibility of just passing an enum as the parameter to a signal. I thought that enum was called status. Have you ever read LyXFunc::getStatus()? It does exactly that, if I understand you correctly. Yes but it shouldn't be doing that (menu changes etc.) unless in a gui-indep manner. And then only if it needs to be done. How often does it [de]activate stuff now that isn't visible on the screen and could be checked as its built? IIRC LyXFunc::status was mostly occupied with changing read-only stuff and deciding what output/export stuff should be set to. 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. If I ever find time I'll rewrite it all the way it should be done ;-) There shouldn't need to be much if any bending. As Marko pointed we could end up with a TOC in a menu, a toolbar and a dialog. They all still need updating. I'd prefer that they were triggered by the same update() signal. A TOC menu that isn't visible, and a dialog that is closed won't be connected to that update signal so we won't be wasting time updating something that the user can't see. The toolbar TOC is likely to be just a copy of the menu TOC (Marko?) so it would only need to be updated when the user opened it (it's not a tearoff as well is it?). A torn-off menu and a dialog would both be connected to the signal and need the same update info. Probably shouldn't pass "section3.1: The new title" that is likely to difficult to do anyway (maybe get away with passing a Paragraph const), just say "update yourself" instead. So we can at least share the same update signal between the different items. Where do you activate that signal from? We should hopefully only need one or two places in the kernel for any given signal. The cursor movements should only need one place for example. The paragraph update signal could probably be in the same place but with a test to see that we have crossed a paragraph boundary. Triggering an updateTOC signal should be possible from some common area of code -- everything that causes a change to the contents of a paragraph will ask for a redraw of the paragraph won't it? Then put the update signal there with a test to make sure the paragraph would appear in the TOC to avoid unnecessary calls. I'm not sure I like the way this thread is heading -- we could end up with a big ugly mess if we don't try to share more stuff between similar things like menus, toolbars and dialogs. Allan. (ARRae)
Re: [PATCH] KDE FormToc cleanup
On 13-Sep-2000 John Levon wrote: Argh, I accidentally sent an old version which won't compile. Sorry ! New one attached No problem I read your mail late enough ;) I'll commit this too! NOW: PLEASE make the next patch with the command: cvs diff -N -u kdewhatever.patch FROM the source root tree (the directory where the Changelog file is). Do you have problems with this? If yes tell me what and we'll see if we can fix them, if not I'll not accept any other patch in any other format! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ With/Without - and who'll deny it's what the fighting's all about? -- Pink Floyd
Re: [PATCH] KDE FormToc cleanup
On 13-Sep-2000 John Levon wrote: I should get some sleep :/ I forgot in my former mail: GOOD WORK!!! I like the new look of the KDE-TOC-DIALOG!!! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I have accepted Provolone into my life!
Re: Comments Notes in LyX
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Why? (some internal comments that should not go to the general Lars public?) Or some parts of a document you are not sure you want to keep around, and you do not want to have in the LaTeX file (bloat? secret?). Some kind of poor man's version control... I just mentionned that because it is so easy with new insets. JMarc
Re: Internationalisation problem: Turkish i's
"Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I suspect that we will not have a good solution for this until
Lars we can begin using Standar C++ locale support and read all files
Lars with the classic locale ('C')
Easy workaround: lyxlex could use a poor-man ascii-only tolower(),
since keywords should only use [a-zA-Z] (at least they do now).
JMarc
[patch] tracking lists changes, (was InsetRef suggestion ...)
On Wed, 13 Sep 2000, Allan Rae wrote: There shouldn't need to be much if any bending. As Marko pointed we could end up with a TOC in a menu, a toolbar and a dialog. They all still need updating. I'd prefer that they were triggered by the same update() signal. A TOC menu that isn't visible, and a dialog that is closed won't be connected to that update signal so we won't be wasting time updating something that the user can't see. Well. If we don't want to mess with each gui toolkit internals and change the menus only if they are visible then we have to update the status of each menuitem regardless to its visibility. Its the way it is done in gnome frontend and the good news is that it is quite fast (at least I haven't seen any slowdown of LyX due to this constant update). I would expect the same in KDE frontend code. However, we don't have any lists in the menus yet in gnome. The toolbar TOC is likely to be just a copy of the menu TOC (Marko?) so it would only need to be updated when the user opened it (it's not a tearoff as well is it?). A torn-off menu and a dialog would both be connected to the signal and need the same update info. Probably shouldn't pass "section3.1: The new title" that is likely to difficult to do anyway (maybe get away with passing a Paragraph const), just say "update yourself" instead. So we can at least share the same update signal between the different items. Where do you activate that signal from? We should hopefully only need one or two places in the kernel for any given signal. The cursor movements should only need one place for example. The paragraph update signal could probably be in the same place but with a test to see that we have crossed a paragraph boundary. Triggering an updateTOC signal should be possible from some common area of code -- everything that causes a change to the contents of a paragraph will ask for a redraw of the paragraph won't it? Then put the update signal there with a test to make sure the paragraph would appear in the TOC to avoid unnecessary calls. The patch included with this mail adds a new class to src/frontends. This class (ListsTracker, any better name???) keeps the copies of TOC, LOF, LOT, and LOA. If any of this lists changes, the corresponding update signal is emitted. The update signal says just "Update using XXX list" without any specific detail of the change. I've used this class to update FormToc in Gnome frontend and it seems to me that we can remove "Refresh" button in this dialog :). The only problem which I see in current implementation is the place in LyX kernel which should call the ListsTracker update method. I think that this method should be called only if LyX has nothing better to do and only once during this "idle" state. I am not aware know such a nice place in lyx code = it will be nice if someone with better knowledge of lyx internals will find such a place. At present, it is called in LyXView updateToolbar and showState methods (makes lyx reallly slow). Actually, I think we can extend the same technique to track the changes in all LyX actions. However, taking into account that current implementation works quite fast it might be not feesable now. I'm not sure I like the way this thread is heading -- we could end up with a big ugly mess if we don't try to share more stuff between similar things like menus, toolbars and dialogs. to better code? Marko tracker.patch.gz tracker.newfiles.tar.gz
Re: [PATCH] KDE FormToc cleanup
On 13-Sep-2000 John Levon wrote: But to do that would require me to have *two* source trees, because cvs won't know about the new files because I can't do "cvs add". Well I guess we can add you to the cvs-readonly list AND this means you CAN do an add ;) just another of those annoying CVS limitations (personally I can't wait for subversion :) Lars what do you say? Could you also give him write access for the kde frontends? 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ He hath eaten me out of house and home. -- William Shakespeare, "Henry IV"
Re: [PATCH] KDE FormToc cleanup
Juergen Vigna [EMAIL PROTECTED] writes: | On 13-Sep-2000 John Levon wrote: | | But to do that would require me to have *two* source trees, because cvs | won't know about the new files because I can't do "cvs add". | | | Well I guess we can add you to the cvs-readonly list AND this means you | CAN do an add ;) yes. | just another of those annoying CVS limitations (personally I can't wait | for subversion :) | | Lars what do you say? Could you also give him write access for the kde | frontends? or only kde? Lgb
Re: lyx-1.1.5fix1 port to OpenBSD
On 13 Sep 2000 09:00:50 +0200, Lars Gullik Bjønnes wrote: | --- po/Makefile.in.in.orig Tue Sep 12 18:57:02 2000 | +++ po/Makefile.in.inTue Sep 12 18:51:04 2000 | @@ -24,6 +24,8 @@ gnulocaledir = $(prefix)/share/locale | gettextsrcdir = $(prefix)/share/gettext/po | subdir = po | | +DESTDIR = | + Why isn't --prefix enough for you? Anyway if this is a general problem with the Makefile.in.in in the gettext, a report should be submitted to the gettex maintainers. I think the OpenBSD-port should only use the native catgets, because this has been security audited and is confirmed to work. GNU gettext is messy, has potential security leaks and doesn't fit well into the system, IMHO. It might even jeopardize the tight overall system security. So it should never be used on any *BSD system. Greets, Arnd
Re: lyx-1.1.5fix1 port to OpenBSD
"Arnd" == Arnd Hanses [EMAIL PROTECTED] writes: Arnd I think the OpenBSD-port should only use the native catgets, Arnd because this has been security audited and is confirmed to work. Arnd GNU gettext is messy, has potential security leaks and doesn't Arnd fit well into the system, IMHO. It might even jeopardize the Arnd tight overall system security. So it should never be used on any Arnd *BSD system. I thought it was only a problem for suid programs... I would not give LyX such special rights, anyway... JMarc
Re: lyx-1.1.5fix1 port to OpenBSD
On 13 Sep 2000, Lars Gullik Bjønnes wrote: Benjamin Karas [EMAIL PROTECTED] writes: | Maintained-by: [EMAIL PROTECTED] (David L. Johnson) Maintained-by: [EMAIL PROTECTED] (Lars Gullik Bjønnes) and the LyX Team ([EMAIL PROTECTED]) In BSD ports, "Maintained-by" means "who maintais this BSD port", not "who maintains the original software". -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
Re: [PATCH] KDE FormToc cleanup
On 13-Sep-2000 Lars Gullik Bjønnes wrote: or only kde? I meant frontends/kde :) 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "The medium is the massage." -- Crazy Nigel
Re: lyx-1.1.5fix1 port to OpenBSD
On Wed, 13 Sep 2000, Arnd Hanses wrote: I think the OpenBSD-port should only use the native catgets, because this has been security audited and is confirmed to work. GNU gettext is messy, has potential security leaks and doesn't fit well into the system, IMHO. It might even jeopardize the tight overall system security. So it should never be used on any *BSD system. Have you patched LyX or any other software to use native catgets? In my system (FreeBSD 4.1-RELEASE) I have gettext-0.10.35 installed because it is required by GNU make and wget, but LyX is statically linked to the included gettext. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
Re: lyx-1.1.5fix1 port to OpenBSD
Carlos A M dos Santos [EMAIL PROTECTED] writes: | On 13 Sep 2000, Lars Gullik Bjønnes wrote: | | Benjamin Karas [EMAIL PROTECTED] writes: | | | Maintained-by: [EMAIL PROTECTED] (David L. Johnson) | | Maintained-by: [EMAIL PROTECTED] (Lars Gullik Bjønnes) and the LyX Team |([EMAIL PROTECTED]) | | In BSD ports, "Maintained-by" means "who maintais this BSD port", not "who | maintains the original software". It is still not [EMAIL PROTECTED] Lgb
Re: lyx-1.1.5fix1 port to OpenBSD
On Wed, Sep 13, 2000 at 05:15:17AM +0100, Arnd Hanses wrote: On 13 Sep 2000 09:00:50 +0200, Lars Gullik Bjønnes wrote: | --- po/Makefile.in.in.orig Tue Sep 12 18:57:02 2000 | +++ po/Makefile.in.in Tue Sep 12 18:51:04 2000 | @@ -24,6 +24,8 @@ gnulocaledir = $(prefix)/share/locale | gettextsrcdir = $(prefix)/share/gettext/po | subdir = po | | +DESTDIR = | + Why isn't --prefix enough for you? Anyway if this is a general problem with the Makefile.in.in in the gettext, a report should be submitted to the gettex maintainers. [snip] Out of context, but I thought I'd answer this as a debian developer. Yes, this does seem to be an upstream problem with gettext. I don't know if it has ever been reported. 'prefix' isn't good enough because packaging systems (certainly dpkg) have to build into a temporary dir, which is not where the package will run from. If I ./configure --prefix=/home/jules/tmproot/usr, then any embedded paths within the application (in general, possibly not in lyx's case) will be /home/jules/tmproot/usr/bin/appname. So in general debian packaging scripts ./configure --prefix=/usr (so that the paths are correct), but make install DESTDIR=/home/jules/tmproot/ (or whatever). Since gettext doesn't support this, this means that some patch is necessary to it every time ;-( Jules
[Ross Moore ross@ics.mq.edu.au] Re: [l2h] newbie, problem with \url + lyx
I've some documents in: http://www.savebylinux.com/latex/ There are 2 file
and 2 directory contain HTML result from each file. I use lattest
latex2html and lyx program. I hope you can explore what's wrong with it.
Thanks.
The fix is very easy:
In the document preamble, just insert the two lines below
beginning with % :
%begin{latexonly}
\IfFileExists{url.sty}{\usepackage{url}}
{\newcommand{\url}{\texttt}}
%end{latexonly}
These "comments" are invisible to LaTeX, but act as environment delimiters
for LaTeX2HTML. The material in-between is filtered out at a very early stage
of processing, hence there can be no incompatibility caused by the
\newcommand{\url}{\texttt}
BTW, (for the Lyx gurus)
would it not be better, partly as a matter of style and efficiency,
to use low-level TeX coding with this conditional code ?
\IfFileExists{url.sty}{\usepackage{url}}{\let\url\texttt}
The reason that LaTeX2HTML has difficulty with a definition such as:
\newcommand{\url}{\texttt}
is that it does not say that (at the user-level) \url should act as if
it takes an argument. When the processor expands macros as in TeX,
then this doesn't matter; but with an alternative expansion model,
it is possible for the \url to get irretrievably separated from its intended
argument. Thus
\newcommand{\url}[1]{\texttt{#1}}
would be a more sympathetic definition for non-TeX,
but the \let version is the most elegent, IMHO.
I hope this provides a complete solution to the compatibility problem.
Thanks in advances.
You're welcome,
Ross Moore
Re: lyx-1.1.5fix1 port to OpenBSD
On Wed, 13 Sep 2000 10:55:11 + (GMT), Carlos A M dos Santos wrote: Have you patched LyX or any other software to use native catgets? In my system (FreeBSD 4.1-RELEASE) I have gettext-0.10.35 installed because it is required by GNU make and wget, but LyX is statically linked to the included gettext. Why, you can always simply disable the translations and remove the fn calls. (BTW: The *BSD's are usually employed out of generalized paranoia for special purposes, so normally you would want to avoid the additional complexity of l8n. E.g., OpenBSD has removed nearly all translations from the system, exactly for security reasons.) Greets, Arnd
Re: lyx-1.1.5fix1 port to OpenBSD
On 13 Sep 2000 12:42:49 +0200, Jean-Marc Lasgouttes wrote: I thought it was only a problem for suid programs... I would not give LyX such special rights, anyway... What, if a talented and qualified intrusor would be able to connect the functions to a suid program? This only means that one leak has already been confirmed, there might exist more potential leaks. OpenBSD, on the other hand, is a maximum paranoia system, written for and by insanely paranoid sysadmins. ;-) Greets, Arnd
Re: lyx-1.1.5fix1 port to OpenBSD
On Wed, 13 Sep 2000, Arnd Hanses wrote: On 13 Sep 2000 12:42:49 +0200, Jean-Marc Lasgouttes wrote: I thought it was only a problem for suid programs... I would not give LyX such special rights, anyway... What, if a talented and qualified intrusor would be able to connect the functions to a suid program? How would this even be possible ? We are discussing the safety of gettext calls, the only way this could be a problem is if a) someone made LyX suid or b) someone used LyX in a suid app Both are obviously wrong things to do, and neither are open to a malicious hacker ... The only security concerns I can see for LyX is /tmp races if LyX is run as root, or a privileged user of some sort, and the attachment/macro virus stuff, which I believe the interested parties are very very aware of ;) This only means that one leak has already been confirmed, there might exist more potential leaks. OpenBSD, on the other hand, is a maximum paranoia system, written for and by insanely paranoid sysadmins. ;-) Some of us have had brushes with Theo before ;) john -- "For every problem there is one solution which is simple, neat, and wrong." - H. L. Mencken
Another apparent problem with NEW_INSETS
With new insets, my FormRef dialog never gets the labels in figure floats that I have in a document (but gets the labels in sections fine). And dispatching a GOTO_REF after explicitly opening up that reference gives the "label not found" error. Lars, I'm sorry I can't debug this further, but I don't have time to work my way round the kernel code right now. If there's anything I can do to help say so thanks john p.s. a quick question, what is the "Name" of a crossref for, and when is it used ? -- "...except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea." - Linus Torvalds
LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000, John Levon wrote: On Wed, 13 Sep 2000, Arnd Hanses wrote: How would this even be possible ? We are discussing the safety of gettext calls, the only way this could be a problem is if a) someone made LyX suid or b) someone used LyX in a suid app Or c) user root using LyX. But remember that security also means protecting user privacity. The only security concerns I can see for LyX is /tmp races if LyX is run as root, or a privileged user of some sort, and the attachment/macro virus stuff, which I believe the interested parties are very very aware of ;) The /tmp races could be avoided by creating a temporary directory, say ~/.lyx/tmp and using it instead of /tmp. I personally dislike the use of a globally writable directory and consider this one of the main flaws in most of the UNIX utilities. Unless I use "umask 077" in my .profile, for example, LyX creates it's temporary files and directories under /tmp with global read permission, so any user in my system can "cd /tmp/lyx_tmp5289aaa/lyx_bufrtmp5289aaa" and read the contents of any file. This may not be good if I'm writing my future plans for total domination. :-) One alternative is install LyX under it's own directory tree by configurin it with "--prefix=/usr/local/lyx" and create a script named /usr/local/bin/lyx containing #!/bin/sh # protect privacity of lyx_tmp* umask 077 exec /usr/local/lyx/bin/lyx "$@" This works well, but has a drawback: all files created LyX will be go-rwx, even those under the home directory. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
Re: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000, Carlos A M dos Santos wrote: One alternative is install LyX under it's own directory tree by configurin it with "--prefix=/usr/local/lyx" Or perhaps renaming it /usr/local/bin/lyx.bin. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
RE: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On 13-Sep-2000 Carlos A M dos Santos wrote: This works well, but has a drawback: all files created LyX will be go-rwx, even those under the home directory. Well wouldn't it be easier to specify in the /usr/local/share/lyx/lyxrc file that you want your files in ~/tmp and create a ~/tmp for every user? Or you could just say tempdir=false so it doesn't use any tempdir and let the user specify it own tempdir if (s)he wants it? This are all options you already have with lyx! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You are an insult to my intelligence! I demand that you log off immediately.
Re: new lyx
On Wed, Sep 13, 2000 at 01:27:11PM +1000, Allan Rae wrote: On Tue, 12 Sep 2000, Amir Karger wrote: OK, so I finally downloaded gcc-2.95.2, so that I could compile the new LyX. I assume someone has noted in the requirements that 2.95 no longer works? Hint: assume nothing. I kind of figured my assumption was wrong. Creative definition of "assume". I assume this is a 2.95.2 thing, not you, since it's coming from the gcc stuff. Still, is it there for a reason? You missed out the important part: the compilation flags. You'll see that Lars has set the -Winline flag which is generating all these messages since gcc can't inline that particular function. IIRC the function in question is a one-liner but that's not important. Does that mean something could be added to the Makefile to fix the problem? Why does nearly every file compilation get this? That just shows how many files are dependent upon the use of maps and other tree based STL containers. Oh, so actually we should be *proud* we're getting so many warnings, because it shows how STL-compliant we are now! -Amir
Re: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000, Carlos A M dos Santos wrote: On Wed, 13 Sep 2000, John Levon wrote: On Wed, 13 Sep 2000, Arnd Hanses wrote: How would this even be possible ? We are discussing the safety of gettext calls, the only way this could be a problem is if a) someone made LyX suid or b) someone used LyX in a suid app Or c) user root using LyX. how does a malicious user insert dangerous environment variables into root's environment ? I can't see this is an issue. Of course, it's bad practice to run things as run as root unless necessary anyway. But remember that security also means protecting user privacity. of course The /tmp races could be avoided by creating a temporary directory, say ~/.lyx/tmp and using it instead of /tmp. I personally dislike the use of a globally writable directory and consider this one of the main flaws in most of the UNIX utilities. yes, well Juergen has already answered this one ;) john -- "...except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea." - Linus Torvalds
Re: new lyx
"Amir" == Amir Karger [EMAIL PROTECTED] writes: Amir Does that mean something could be added to the Makefile to fix Amir the problem? Rather that this -Winlline should be removed. Why does nearly every file compilation get this? That just shows how many files are dependent upon the use of maps and other tree based STL containers. Amir Oh, so actually we should be *proud* we're getting so many Amir warnings, because it shows how STL-compliant we are now! From what I read in the STL sources, it seems that a creative programmer decided to declare 'inline' a recursive function. We are lucky that the compiler does not generate a 10Gb+ binary :) JMarc
Re: new lyx
Oh, so actually we should be *proud* we're getting so many warnings, because it shows how STL-compliant we are now! Which reminds me: Under http://sources.redhat.com/ml/libstdc++/2000-q2/msg00700/sstream there is a rather straightforward implementation of sstringstreams. I have been using it for a while now and there seems to be no problem with it. Maybe this could be added to support/ and used in cases when there there is no "native" stringstream available? This way we could get rid of all these #ifdef HAVE_SSTREAM... Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: new lyx
Andre Poenitz [EMAIL PROTECTED] writes: | Oh, so actually we should be *proud* we're getting so many warnings, because | it shows how STL-compliant we are now! | | Which reminds me: | | Under | | http://sources.redhat.com/ml/libstdc++/2000-q2/msg00700/sstream | | there is a rather straightforward implementation of sstringstreams. | I have been using it for a while now and there seems to be no problem | with it. | | Maybe this could be added to support/ and used in cases when there | there is no "native" stringstream available? | | This way we could get rid of all these #ifdef HAVE_SSTREAM... This idea is not half bad... let me have a look. Does it work with gcc 2.95.2, without problems? The only think I see can play tricks on us is the use of string... but we certainly can hack it a bit ourselves. Lgb
RE: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000, Juergen Vigna wrote: Well wouldn't it be easier to specify in the /usr/local/share/lyx/lyxrc file that you want your files in ~/tmp and create a ~/tmp for every user? It's undocumented, at least in 1.1.4, but following your suggestion I found an example into lyxrc.example, thanks. Or you could just say tempdir=false so it doesn't use any tempdir and let the user specify it own tempdir if (s)he wants it? This would let temporary files in my working directories. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
class_choice - combo_class
Hi! As Jean-Marc proposed I changed the choice_class in the FormDocument to be a combo-box as it could get pretty long and go over the screen border (a report we already had). Now I've a problem, when I select a new class I get a question from the system if I want also change the layouts of paragraphs. Now the combox did a mouse-grab so I'm not able to click with the mouse on the yes/no buttons (i use kb-y)! The question is "Do we really need this question here?!" Wouldn't it be better to give this question when we press the apply button? Well I'll change it to do right this when using a combox and have a define USE_CLASS_COMBO, until someone points me out a better solution! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I know the answer! The answer lies within the heart of all mankind! The answer is twelve? I think I'm in the wrong building. -- Charles Schulz
[PATCH] KDE FormRef
Lars, I've confirmed it's not KDE code that's causing the weirdness with NEW_INSETS defined. I see you ignored my previous comments so I must be saying something really stupid :( This is 95%, as there is still a big hole when we edit an existing crossref, and we hide the refs list. It seems difficult to get Qt to redo the layout, and remove the widget 2000-09-13 John Levon [EMAIL PROTECTED] * src/frontends/kde/Makefile.am * src/frontends/kde/FormRef.C * src/frontends/kde/FormRef.h * src/frontends/kde/formrefdialog.C * src/frontends/kde/formrefdialog.h: implement cross-ref dialog thanks john -- "There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has now come true, since I no longer know how to use my telephone." - Bjarne Stroustrap formref.tar.gz
Re: [PATCH] KDE FormRef
John Levon [EMAIL PROTECTED] writes: | Lars, I've confirmed it's not KDE code that's causing the weirdness with | NEW_INSETS defined. I see you ignored my previous comments so I must be | saying something really stupid :( It is not that I am ignoring it. More that I don't have time to look into this right now. Anyway if you want to help you should use the XForms frontend first and help make that work. Then we should check the other frontends. There are areas where NEW_INSETS are not finished, even if I didn't think this was one of them. Lgb
RE: [PATCH] KDE FormRef
On 13-Sep-2000 John Levon wrote: 2000-09-13 John Levon [EMAIL PROTECTED] * src/frontends/kde/Makefile.am * src/frontends/kde/FormRef.C * src/frontends/kde/FormRef.h * src/frontends/kde/formrefdialog.C * src/frontends/kde/formrefdialog.h: implement cross-ref dialog There is still the Changelog missing in the diff-file please resubmit! Have a nice evening, Jürgen P.S.: Lars did you already give John cvs rights? -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Avoid reality at all costs.
RE: [PATCH] KDE FormRef
On Wed, 13 Sep 2000, Juergen Vigna wrote: There is still the Changelog missing in the diff-file please resubmit! sorry, I thought it was as other projects, where the changelog doesn't go in the diff so there's not syncing problems between patches. New one with Changelog diff included. Sorry to be a bother ;) thanks john -- "There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has now come true, since I no longer know how to use my telephone." - Bjarne Stroustrap formref.tar.gz
Re: [PATCH] KDE FormRef
On 13 Sep 2000, Lars Gullik Bjønnes wrote: It is not that I am ignoring it. More that I don't have time to look into this right now. of course, sorry to suggest otherwise Anyway if you want to help you should use the XForms frontend first and help make that work. Then we should check the other frontends. I'll do what I can but I think I will not be much use as I don't know the main LyX code hardly at all. There are areas where NEW_INSETS are not finished, even if I didn't think this was one of them. Lgb OK, thanks Lars john -- "There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has now come true, since I no longer know how to use my telephone." - Bjarne Stroustrap
Re: [PATCH] KDE FormRef
Juergen Vigna [EMAIL PROTECTED] writes: | Jürgen | | P.S.: Lars did you already give John cvs rights? No, but I will. Lgb
Re: class_choice - combo_class
"Juergen" == Juergen Vigna [EMAIL PROTECTED] writes: Juergen Now I've a problem, when I select a new class I get a Juergen question from the system if I want also change the layouts of Juergen paragraphs. Now the combox did a mouse-grab so I'm not able Juergen to click with the mouse on the yes/no buttons (i use kb-y)! Isn't it possible to close the combox before changing the layout? JMarc
RE: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000 14:43:43 + (GMT), Carlos A M dos Santos wrote: On Wed, 13 Sep 2000, Juergen Vigna wrote: Well wouldn't it be easier to specify in the /usr/local/share/lyx/lyxrc file that you want your files in ~/tmp and create a ~/tmp for every user? It's undocumented, at least in 1.1.4, but following your suggestion I found an example into lyxrc.example, thanks. And security/privacy means always security/privacy to be enforced by default, unless somebody who knows what he is doing decides against them. (Most commercial Linux distributions entirely would disagree; but they are biased, because they must survive in M$ biotopes! ;- And this is not at all meant pejoratively!) So the default as well as the fallback should be some ~/.lyx/tmp/ directory. This would leave behind tmp files in case of a LyX crash, which is only a good thing, isn't it? Arnd PS: We should never underestimate the enormous amount of creativity unleashed by pure maliciousness... So we (the less careful) need the paranoid, as they are the only ones to really understand and to pull the brakes in today's feature rat race.
RE: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000, Arnd Hanses wrote: On Wed, 13 Sep 2000 14:43:43 + (GMT), Carlos A M dos Santos wrote: And security/privacy means always security/privacy to be enforced by default, unless somebody who knows what he is doing decides against them. (Most commercial Linux distributions entirely would disagree; but they are biased, because they must survive in M$ biotopes! ;- And this is not at all meant pejoratively!) well I think if someone is writing sensitive information in a multi-user environment, they'd better know about this anyway. It would be up to the system administrator to set a global umask or whatever otherwise ... So the default as well as the fallback should be some ~/.lyx/tmp/ directory. This would leave behind tmp files in case of a LyX crash, which is only a good thing, isn't it? well, I have a feeling this would bring many complaints from university students with small quotas and large reports ;) yes, it would be configurable, but I think /tmp is a reasonable default (I agree that this world-writable directory thing was always a bad idea though) Or does LyX default to $TMPDIR ? Arnd PS: We should never underestimate the enormous amount of creativity unleashed by pure maliciousness... Yep, I read BUGTRAQ ;) john -- "There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has now come true, since I no longer know how to use my telephone." - Bjarne Stroustrap
Re: [PATCH] KDE FormToc cleanup
On Wed, Sep 13, 2000 at 11:27:40AM +0200, Juergen Vigna wrote: On 13-Sep-2000 John Levon wrote: I should get some sleep :/ I forgot in my former mail: GOOD WORK!!! I like the new look of the KDE-TOC-DIALOG!!! The Klyx TOC dialog is a little bit nicer (e.g. the ability to select a depth threshold). John, why aren't you reusing code from Klyx ?
Re: new lyx
Does it work with gcc 2.95.2, without problems? I am using 2.95.2-2 and this sstring file is the only enhancement over the "official" (SuSE or RedHat) .rpm . So I'd say: yes. Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Re: new lyx
Andre Poenitz [EMAIL PROTECTED] writes: | Does it work with gcc 2.95.2, without problems? | | I am using 2.95.2-2 and this sstring file is the only enhancement over | the "official" (SuSE or RedHat) .rpm . | | So I'd say: yes. Have you tried to use it together with lyxstring? Lgb
SIGSEGV signal caught
Hello! I'm using Lyx under LinuxPPC, kernel 2.2.17pre13-ben1 on an iMac DV. I was using the Xpmac X server and everything was going fine (by the way, I think I couldn't live without lyx now...) Today, I changed my X server to XFree 4.0. Everything seems to be fine, excepted that lyx doesn't start any more... That bothers me very much, because I use Linux mainly because of lyx... When I run Lyx from the console, I get lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' under the Help menu and then send us a full bug report. Thanks! Bye. Aborted (core dumped) I also send the core file as an attachment. I would be very grateful if a fix exists. Otherwise, I'm gonna try to change back my to my old X server... I don't read any of the lyx lists. Thank you to send me a copy of your answer. Thank you for your help, Matthieu NB: I did NOT read the known bugs under Lyx Help, because precisely I'm not able to start Lyx! core
Re: new lyx
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | | So I'd say: yes. | | Have you tried to use it together with lyxstring? One small problem is that it requires rtti (I am not sure why), so I rewrote a tiny bit to not use te dynamic_cast. I am trying it within LyX now. I will report back results later.
Re: Comments Notes in LyX
"Lars Gullik Bjønnes" wrote:
| 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.
Why? (some internal comments that should not go to the general
public?)
Hi,
I am currently in the process of replacing Interleaf (a big publishing
package like Framemaker) with LyX/Latex.
I have managed to write a Python program that converts our Interleaf
documents . This convinced a few of my coworkers that LyX is a great
choice since editing in LyX is more intuitive than in Interleaf
(bibliography and indexes are really better).
We have a few features that we would need to convince erverybody that
LyX IS THE WAY to go :
- be able to tag some layout (a paragraph, an item in list etc.) to make
them selectively disappear.
example : you tag an itemize layout with CUSTOMER_A and when you print
with CUSTOMER_B option, this
text will NOT be printed.
This is a good replacement for comments too. (That's why I take part
in this thread, I peeked further in the thread and some people seem to
agree with me)
- XML format. this is not a real problem since I have shown that a basic
utility to write LyX files could be written in less than one day. I
think they will trust me if I say that we could export our LyX files to
some XML format in a few day. Anyway I really think that the current
format is strange ('end float' is not the same as 'end float ' !!) and
XML would be an EASY and FASHIONABLE replacement.
The first item is really the most important. Could you help ? I would
be willing to do the coding, though I am an Ada coder at work...
P.O. Gaillard
thinking aloud about phantom text styles
This has been fermenting between the ears for some time now, and only picked up concrete form the other day. I want to have a type of text tjat can be excluded in a "save as" operation. Alternatively, there could be an abridged export to lyx operation. Text marked in this way would act as normal text unless excluded in such an operation. This is similar to what the "slides only" and "notes only" in the slides class are supposed to do (has anyone gotten either of those to work, for that matter?) My specific use would be having a single file containing both the test (or homework) and the key. I could then distribute the exported file while holding back the answers, yet keep the questions in the key and the test fully in sync (not that *I* have ever ended up with different versions :). My initial approach was to to define an "answer" style that could be made to go away with a switch. This leave the problem, though, of not being able to distribute the lyx or latex files, which I usually do on a web page. The idea isn't fully developed, and I'm not yet certain that I can't solve it with just a document class. It would, however, be very useful. But before I set about it, I want to make sure I'm not reinventing the wheel . . . --
Re: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
John Levon wrote: On Wed, 13 Sep 2000, Arnd Hanses wrote: On Wed, 13 Sep 2000 14:43:43 + (GMT), Carlos A M dos Santos wrote: And security/privacy means always security/privacy to be enforced by default, unless somebody who knows what he is doing decides against them. (Most commercial Linux distributions entirely would disagree; but they are biased, because they must survive in M$ biotopes! ;- And this is not at all meant pejoratively!) well I think if someone is writing sensitive information in a multi-user environment, they'd better know about this anyway. It would be up to the system administrator to set a global umask or whatever otherwise ... So the default as well as the fallback should be some ~/.lyx/tmp/ directory. This would leave behind tmp files in case of a LyX crash, which is only a good thing, isn't it? well, I have a feeling this would bring many complaints from university students with small quotas and large reports ;) yes, it would be configurable, but I think /tmp is a reasonable default (I agree that this world-writable directory thing was always a bad idea though) Why not set up the /tmp/lyx_... directory itself as mode 700? Shouldn't this take care of the issue at hand? Carl -- Carl Ollivier-Gooch [EMAIL PROTECTED] Department of Mechanical EngineeringVoice: +1-604-822-1854 University of British Columbia Fax: +1-604-822-2403 2324 Main Mall URL: http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 Canada --
Re: thinking aloud about phantom text styles
hawk wrote: This has been fermenting between the ears for some time now, and only picked up concrete form the other day. I want to have a type of text tjat can be excluded in a "save as" operation. Alternatively, there could be an abridged export to lyx operation. Text marked in this way would act as normal text unless excluded in such an operation. This is similar to what the "slides only" and "notes only" in the slides class are supposed to do (has anyone gotten either of those to work, for that matter?) My specific use would be having a single file containing both the test (or homework) and the key. I could then distribute the exported file while holding back the answers, yet keep the questions in the key and the test fully in sync (not that *I* have ever ended up with different versions :). My initial approach was to to define an "answer" style that could be made to go away with a switch. This leave the problem, though, of not being able to distribute the lyx or latex files, which I usually do on a web page. The idea isn't fully developed, and I'm not yet certain that I can't solve it with just a document class. It would, however, be very useful. But before I set about it, I want to make sure I'm not reinventing the wheel . . . I've chosen your initial approach. Another nice thing, though, would be to have three levels: assignment/quiz, with solutions added, or with solutions -and- notes to markers added. To protect my markers from student flack, I don't distribute the marking guide to students. But I distribute in PDF format online, so I can live with the easy solution. Let me know if anything interesting comes of it. Carl -- -- Carl Ollivier-Gooch [EMAIL PROTECTED] Department of Mechanical EngineeringVoice: +1-604-822-1854 University of British Columbia Fax: +1-604-822-2403 2324 Main Mall URL: http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 Canada --
Re: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000 13:08:24 -0700, Carl Ollivier-Gooch wrote: And security/privacy means always security/privacy to be enforced by default, unless somebody who knows what he is doing decides against them. (Most commercial Linux distributions entirely would disagree; but they are biased, because they must survive in M$ biotopes! ;- And this is not at all meant pejoratively!) well I think if someone is writing sensitive information in a multi-user environment, they'd better know about this anyway. It would be up to the system administrator to set a global umask or whatever otherwise ... Life tells us you never knew beforehand something was sensitive, eventually. So the default as well as the fallback should be some ~/.lyx/tmp/ directory. This would leave behind tmp files in case of a LyX crash, which is only a good thing, isn't it? well, I have a feeling this would bring many complaints from university students with small quotas and large reports ;) yes, it would be configurable, but I think /tmp is a reasonable default (I agree that this world-writable directory thing was always a bad idea though) Why not set up the /tmp/lyx_... directory itself as mode 700? Shouldn't this take care of the issue at hand? hmm... CHMOD(2) FreeBSD System Calls Manual NAME chmod, fchmod, lchmod - change mode of file SYNOPSIS #include sys/stat.h int chmod(const char *path, mode_t mode) [...] DESCRIPTION The file permission bits of the file name specified by path or refer- enced by the file descriptor fd are changed to mode. The chmod() function verifies that the process owner (user) either owns the file specified by path (or fd), or is the super-user. [...] While a LyX-user is unlikely to be the owner of /tmp he would be the owner of self-created sub-directories. So I think this is a good idea... Arnd
Re: SIGSEGV signal caught
On Wed, 13 Sep 2000, Matthieu Amiguet wrote: Hello! Hello, Matthieu. First a tip: Don't post multi-megabyte files to any mailing list put the file on a web or ftp server and provide a link. Second tip: All LyX files are ascii, so even if LyX doesn't start you can still read the file using 'more' or 'less'. I'm using Lyx under LinuxPPC, kernel 2.2.17pre13-ben1 on an iMac DV. I was using the Xpmac X server and everything was going fine (by the way, I think I couldn't live without lyx now...) Today, I changed my X server to XFree 4.0. Everything seems to be fine, excepted that lyx doesn't start any more... That bothers me very much, because I use Linux mainly because of lyx... When I run Lyx from the console, I get lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' under the Help menu and then send us a full bug report. Thanks! Bye. Aborted (core dumped) If you have gdb installed you can do some helpful stuff for us that means you don't need to send core files -- we don't really want these anyway (my mailbox quota was competely overblown). Do this: gdb lyx | tee lyx-dump.txt once gdb starts you'll get a prompt: (gdb): at the prompt type: (gdb): run when lyx crashes type (gdb): bt then type: (gdb): up a few times till you get to LyX code. You'll know you are there when you start seeing lines of code printed after the prompt. (gdb): info locals (gdb): up repeat these steps a couple of times. Then type: (gdb): quit Send us the lyx-dump.txt file. Allan. (ARRae)
Re: SIGSEGV signal caught
Anyone have a problem with me adding this as lyx-devel/BUGS? I'll add a bit more as well. Allan. (ARRae) On Thu, 14 Sep 2000, Allan Rae wrote: If you have gdb installed you can do some helpful stuff for us that means you don't need to send core files -- we don't really want these anyway (my mailbox quota was competely overblown). Do this: gdb lyx | tee lyx-dump.txt once gdb starts you'll get a prompt: (gdb): at the prompt type: (gdb): run when lyx crashes type (gdb): bt then type: (gdb): up a few times till you get to LyX code. You'll know you are there when you start seeing lines of code printed after the prompt. (gdb): info locals (gdb): up repeat these steps a couple of times. Then type: (gdb): quit Send us the lyx-dump.txt file.
[PATCH] hollywood.cls
One of our users has made some well researched suggestions for changes
to the hollywood.cls file.
The diff from cvs -N -u is attached, including the Changelog.
Garst
Index: lyx-devel/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
retrieving revision 1.524
diff -u -u -r1.524 ChangeLog
--- lyx-devel/ChangeLog 2000/09/13 15:07:05 1.524
+++ lyx-devel/ChangeLog 2000/09/14 04:50:23
@@ -1,3 +1,9 @@
+2000-09-14 Garst Reese[EMAIL PROTECTED]
+ * lib/tex/hollywood.cls changed length of parenthicals to 1.5in
+ moved usepackage{xxx}'s to beginning of file. Changed left margin
+ to 1.5in, right margin to 1in. Forced headrulewidth to 0, removed
+ underlining from title. Thanks to John Culleton for useful suggestions.
+
2000-09-13 Juergen Vigna [EMAIL PROTECTED]
* src/frontends/xforms/FormDocument.C: implemented choice_class
Index: lyx-devel/lib/tex/hollywood.cls
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/tex/hollywood.cls,v
retrieving revision 1.4
diff -u -u -r1.4 hollywood.cls
--- lyx-devel/lib/tex/hollywood.cls 2000/05/22 13:20:51 1.4
+++ lyx-devel/lib/tex/hollywood.cls 2000/09/14 04:50:25
@@ -6,6 +6,11 @@
%% that could be deleted.
\NeedsTeXFormat{LaTeX2e}
\ProvidesClass{hollywood} [1998/10/27 v1.0 uses hollywood.layout]
+\usepackage{fancyhdr}
+\usepackage{extramarks}
+\usepackage{ifthen}
+\usepackage{lastpage}
+\pagestyle{fancy}
\renewcommand{\ref}[1]{#1}
\newcommand\@ptsize{}
\newif\if@restonecol
@@ -42,7 +47,7 @@
\@medpenalty 151
\@highpenalty 301
\setcounter{topnumber}{2}
-% \renewcommand{\headrulewidth}{0pt}
+\renewcommand{\headrulewidth}{0pt}
\renewcommand\topfraction{.7}
\setcounter{bottomnumber}{1}
\renewcommand\bottomfraction{.3}
@@ -73,7 +78,8 @@
\null\vfil
\vskip 60\p@
\begin{center}%
-{ \underline{\@title} \par}%
+%%{ \underline{\@title} \par}%
+{ \@title \par}%
\vskip 3em%
{\lineskip .75em%
\begin{tabular}[t]{c}%
@@ -155,11 +161,6 @@
\else
\onecolumn
\fi
-\usepackage{fancyhdr}
-\usepackage{extramarks}
-\usepackage{ifthen}
-\usepackage{lastpage}
-\pagestyle{fancy}
% This stuff is for a shooting script
% \lhead{\ifthenelse{ \not \value{page} = 1}{CONTINUED:}{}}
% \rfoot{\ifthenelse{ \not \value{page}=\pageref{LastPage}}{(CONT'D)}
@@ -169,7 +170,6 @@
% This is what we want for a spec script
\rhead{\thepage.}
\cfoot{}
-% \renewcommand{\headrulewitdh}{0pt}
% This one is needed to get real adobe courier, but you can use
% cmtt which is also correct
\renewcommand{\familydefault}{pcr}
@@ -210,7 +210,7 @@
\newcommand{\parenthetical}[1]%
{\raggedright
\hspace{1.75in}
-\parbox{3in}{(#1)}
+\parbox{1.5in}{(#1)}
\vspace{6pt}}
\endinput
Index: lyx-devel/po/POTFILES.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/po/POTFILES.in,v
retrieving revision 1.66
diff -u -u -r1.66 POTFILES.in
--- lyx-devel/po/POTFILES.in2000/09/12 17:25:44 1.66
+++ lyx-devel/po/POTFILES.in2000/09/14 04:50:25
@@ -56,6 +56,14 @@
src/frontends/xforms/form_print.C
src/frontends/xforms/FormRef.C
src/frontends/xforms/form_ref.C
+src/frontends/xforms/forms/form_citation.C
+src/frontends/xforms/forms/form_copyright.C
+src/frontends/xforms/forms/form_graphics.C
+src/frontends/xforms/forms/form_preferences.C
+src/frontends/xforms/forms/form_print.C
+src/frontends/xforms/forms/form_tabular.C
+src/frontends/xforms/forms/form_toc.C
+src/frontends/xforms/forms/form_url.C
src/frontends/xforms/FormTabular.C
src/frontends/xforms/form_tabular.C
src/frontends/xforms/FormToc.C
Re: [PATCH] KDE FormRef
On Wed, 13 Sep 2000, John Levon wrote: This is 95%, as there is still a big hole when we edit an existing crossref, and we hide the refs list. It seems difficult to get Qt to redo the layout, and remove the widget Just disable it then. You don't have to make the KDE port work and look just like the XForms port does. Allan. (ARRae)
Re: I'm back, take 2 :)
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "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.
This is also an artifact of the new menu code. It is not LyX that
open the menus anymore, it is XForms. (a lot saner imho)
| Lars does not
| want to have M-m bindings which are not real menu bindings. I'd be
| surprised if people like it %-]
What is the problem with changing it to "C-m {"?
Lgb
Re: Comments & Notes in LyX
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "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. Why? (some internal comments that should not go to the general public?) Currently we have both a comment paragraph layout and a note inset, I am not sure that we need both. Lgb
[PATCH] KDE FormToc cleanup
2000-09-13 John Levon <[EMAIL PROTECTED]>
* src/frontends/kde/formtocdialog.C
* src/frontends/kde/formtocdialog.h
* src/frontends/kde/FormToc.C
* src/frontends/kde/FormToc.h: change to
make TOC hierarchical properly
? formtoc.diff
Index: FormToc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/kde/FormToc.C,v
retrieving revision 1.1
diff -u -r1.1 FormToc.C
--- FormToc.C 2000/09/12 15:13:18 1.1
+++ FormToc.C 2000/09/13 06:35:32
@@ -15,6 +15,8 @@
#include
+#include
+
#include "formtocdialog.h"
#include "Dialogs.h"
@@ -28,6 +30,7 @@
using std::vector;
using std::pair;
+using std::stack;
FormToc::FormToc(LyXView *v, Dialogs *d)
: dialog_(0), lv_(v), d_(d), inset_(0), h_(0), u_(0), ih_(0),
@@ -92,18 +95,59 @@
toclist = tmp[type];
dialog_->tree->clear();
+
+ dialog_->tree->setUpdatesEnabled(false);
-
- // FIXME: should do hierarchically. at each point we need to know
- // id of item we've just inserted, id of most recent sibling, and
- // id of parent
+ int depth = 0;
+ stack< pair< QListViewItem *, QListViewItem *> > istack;
+ QListViewItem *last = 0;
+ QListViewItem *parent = 0;
+ QListViewItem *item;
+
+ // Yes, it is this ugly. Two reasons - root items must have a QListView
+parent,
+ // rather than QListViewItem; and the TOC can move in and out an arbitrary
+number
+ // of levels
- dialog_->tree->setAutoUpdate(false);
for (vector< Buffer::TocItem >::const_iterator iter = toclist.begin();
iter != toclist.end(); ++iter) {
- dialog_->tree->insertItem((string(4*(*iter).depth,'
')+(*iter).str).c_str(), 0, -1, false);
+ if (iter->depth == depth) {
+ // insert it after the last one we processed
+ if (!parent)
+ item = (last) ? (new
+QListViewItem(dialog_->tree,last)) : (new QListViewItem(dialog_->tree));
+ else
+ item = (last) ? (new QListViewItem(parent,last)) :
+(new QListViewItem(parent));
+ } else if (iter->depth > depth) {
+ int diff = iter->depth - depth;
+ // first save old parent and last
+ while (diff--)
+ istack.push(pair< QListViewItem *, QListViewItem *
+>(parent,last));
+ item = (last) ? (new QListViewItem(last)) : (new
+QListViewItem(dialog_->tree));
+ parent = last;
+ } else {
+ int diff = depth - iter->depth;
+ pair< QListViewItem *, QListViewItem * > top;
+ // restore context
+ while (diff--) {
+ top = istack.top();
+ istack.pop();
+ }
+ parent = top.first;
+ last = top.second;
+ // insert it after the last one we processed
+ if (!parent)
+ item = (last) ? (new
+QListViewItem(dialog_->tree,last)) : (new QListViewItem(dialog_->tree));
+ else
+ item = (last) ? (new QListViewItem(parent,last)) :
+(new QListViewItem(parent));
+ }
+ lyxerr[Debug::GUI] "Table of contents" << endl << "Added item " <<
+iter->str.c_str()
+ << " at depth " << iter->depth << ", previous sibling \"" <<
+(last ? last->text(0) : "0")
+ << "\", parent \"" << (parent ? parent->text(0) : "0") << "\""
+<< endl;
+ item->setText(0,iter->str.c_str());
+ depth = iter->depth;
+ last = item;
}
- dialog_->tree->setAutoUpdate(true);
+
+ dialog_->tree->setUpdatesEnabled(true);
dialog_->tree->update();
}
@@ -113,15 +157,19 @@
switch (type) {
case Buffer::TOC_TOC:
dialog_->setCaption(_("Table of Contents"));
+ dialog_->tree->setColumnText(0,_("Table of Contents"));
break;
case Buffer::TOC_LOF:
dialog_->setCaption(_("List of Figures"));
+ dialog_->tree->setColumnText(0,_("List of Figures"));
break;
case Buffer::TOC_LOT:
dialog_->setCaption(_("List of Tables"));
+ dialog_->tree->setColumnText(0,_("List of Tables"));
break;
case Buffer::TOC_LOA:
Re: dotfill,hrulefill status & open behavior
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | I'll start with the open behavior. | I click open and give a new file name. LyX asks if it wants to create | the new file and I answer yes. I later try to save the file and it asks | for a file name. | I enter the same file name that I entered before. LyX saves the file in | /home/garst instead of /home/garst/lyxdocs which is specifed in my | lyxrc. Is this your code playing tricks on us Jürgen? Or it is something older/else? | I think Lars was working on adding dotfill and hrulefill to the insert | special character menu. I looked at it... but it really involves a bit more than just the menu... Lgb
Re: [PATCH] Fix KDE Citation thinko
John Levon <[EMAIL PROTECTED]> writes: | On Tue, 12 Sep 2000, John Levon wrote: | | > | > Doh ! | > | > (There also seems to a problem with FormToc - namely the list-of-figures | > from getTocList seems to empty, even when it shouldn't be. Can someone | > double check it works for xforms/kde, because my older CVS at home doesn't | > seem to have this problem ... | > | | In fact turning off NEW_INSETS, I don't see a problem, it works fine. Lars | ? Or is this not supposed to be working yet ? NEW_INSETS are supposed to be working (in almost all cases), so it it doesn't you have found a bug. Please help to fix it. Lgb
Re: [PATCH] Fix KDE Citation thinko
On 13 Sep 2000, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On Tue, 12 Sep 2000, John Levon wrote: > | > | > > | > Doh ! > | > > | > (There also seems to a problem with FormToc - namely the list-of-figures > | > from getTocList seems to empty, even when it shouldn't be. Can someone > | > double check it works for xforms/kde, because my older CVS at home doesn't > | > seem to have this problem ... > | > > | > | In fact turning off NEW_INSETS, I don't see a problem, it works fine. Lars > | ? Or is this not supposed to be working yet ? > > NEW_INSETS are supposed to be working (in almost all cases), so it it > doesn't you have found a bug. Please help to fix it. > > Lgb > Of course ! I'll have a look now. FWIW I seem to remember from yesterday that the TOC_LOF part of toclist was empty from the getTocList() point of view. TOC_TOC worked fine, I didn't test the others. thanks john -- "I bet the human brain is a kludge." - Marvin Minsky
Re: lyx-1.1.5fix1 port to OpenBSD
Benjamin Karas <[EMAIL PROTECTED]> writes: | Hello, | | I'm working on a port of lyx-1.1.5fix1 to OpenBSD. Everything compiled | fine, but two Makefiles gave me some trouble doing a fake install. I've | attached patches for po/Makefile.in.in and intl/Makefile.in. The changes | shouldn't break anything. | | I'm reusing the old DESC and COMMENT files. I think they should be | updated, but I'm not sure what a good description would be. Here are the | old ones: | | --( COMMENT )-- | graphical frontend for LaTeX (Almost WYSIWYG) | --*-*-- | | --( DESC )-- | LyX is a wordprocessor frontend to LaTeX, which gives both the | ease-of-use of a wordprocessor, and the flexibility and power of | LaTeX. | | Quasi-WYSIWYG interface, many LaTeX styles and layouts automatically | generated. Speeds up learning LaTeX and makes complicated layouts | easy and intuitive. New features include spell-checking, international | character support, WYSIWYG graphics, tables, and equations. | | Author: [EMAIL PROTECTED] (Matthias | Ettrich) Autor: The LyX Team ([EMAIL PROTECTED]) | Maintained-by: [EMAIL PROTECTED] (David L. Johnson) Maintained-by: [EMAIL PROTECTED] (Lars Gullik Bjønnes) and the LyX Team ([EMAIL PROTECTED]) | --*-*-- | | I'll be submitting this to the OpenBSD port maintainers in a day or two | and will incorporate any suggestions you have. | | Thanks. | | Benjamin Karas | [EMAIL PROTECTED] | Tippit 430E; 216.754.2004 | | --- po/Makefile.in.in.origTue Sep 12 18:57:02 2000 | +++ po/Makefile.in.in Tue Sep 12 18:51:04 2000 | @@ -24,6 +24,8 @@ gnulocaledir = $(prefix)/share/locale | gettextsrcdir = $(prefix)/share/gettext/po | subdir = po | | +DESTDIR = | + Why isn't --prefix enough for you? Anyway if this is a general problem with the Makefile.in.in in the gettext, a report should be submitted to the gettex maintainers. Lgb
Re: Comments & Notes in LyX
Allan Rae <[EMAIL PROTECTED]> writes: | On 13 Sep 2000, Lars Gullik Bjønnes wrote: | | > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > | > | > "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. | > | > Why? (some internal comments that should not go to the general | > public?) | > | > Currently we have both a comment paragraph layout and a note inset, I | > am not sure that we need both. | | You may recall the request a week or so ago for a glorified version of | notes to assist in editting -- the notes are a great feature (especially | the bold yellow label) and the request asked for better navigation between | notes (I forget what name they suggested). | | Notes for editting/proofreading are different to comments. I'd like a | full support for the comment environment so we don't change paragraph | styles when we make something a comment. But I want/need editting notes | also -- as do others. | | Both styles of "comments" should be supported imo (both as collapsible | insets so we can eradicate another dialog). Very well, expect that in 1.2.0 then. NEW_INSETS should be enabled for this. Lgb
Re: [PATCH] KDE FormToc cleanup
Argh, I accidentally sent an old version which won't compile.
Sorry ! New one attached
I should get some sleep :/
thanks
john
On Wed, 13 Sep 2000, John Levon wrote:
2000-09-13 John Levon <[EMAIL PROTECTED]>
* src/frontends/kde/formtocdialog.C
* src/frontends/kde/formtocdialog.h
* src/frontends/kde/FormToc.C
* src/frontends/kde/FormToc.h: change to
make TOC hierarchical properly
? a
? formtoc.diff
Index: FormToc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/kde/FormToc.C,v
retrieving revision 1.1
diff -u -r1.1 FormToc.C
--- FormToc.C 2000/09/12 15:13:18 1.1
+++ FormToc.C 2000/09/13 07:05:21
@@ -15,6 +15,8 @@
#include
+#include
+
#include "formtocdialog.h"
#include "Dialogs.h"
@@ -28,6 +30,7 @@
using std::vector;
using std::pair;
+using std::stack;
FormToc::FormToc(LyXView *v, Dialogs *d)
: dialog_(0), lv_(v), d_(d), inset_(0), h_(0), u_(0), ih_(0),
@@ -92,18 +95,59 @@
toclist = tmp[type];
dialog_->tree->clear();
+
+ dialog_->tree->setUpdatesEnabled(false);
-
- // FIXME: should do hierarchically. at each point we need to know
- // id of item we've just inserted, id of most recent sibling, and
- // id of parent
+ int depth = 0;
+ stack< pair< QListViewItem *, QListViewItem *> > istack;
+ QListViewItem *last = 0;
+ QListViewItem *parent = 0;
+ QListViewItem *item;
+
+ // Yes, it is this ugly. Two reasons - root items must have a QListView
+parent,
+ // rather than QListViewItem; and the TOC can move in and out an arbitrary
+number
+ // of levels
- dialog_->tree->setAutoUpdate(false);
for (vector< Buffer::TocItem >::const_iterator iter = toclist.begin();
iter != toclist.end(); ++iter) {
- dialog_->tree->insertItem((string(4*(*iter).depth,'
')+(*iter).str).c_str(), 0, -1, false);
+ if (iter->depth == depth) {
+ // insert it after the last one we processed
+ if (!parent)
+ item = (last) ? (new
+QListViewItem(dialog_->tree,last)) : (new QListViewItem(dialog_->tree));
+ else
+ item = (last) ? (new QListViewItem(parent,last)) :
+(new QListViewItem(parent));
+ } else if (iter->depth > depth) {
+ int diff = iter->depth - depth;
+ // first save old parent and last
+ while (diff--)
+ istack.push(pair< QListViewItem *, QListViewItem *
+>(parent,last));
+ item = (last) ? (new QListViewItem(last)) : (new
+QListViewItem(dialog_->tree));
+ parent = last;
+ } else {
+ int diff = depth - iter->depth;
+ pair< QListViewItem *, QListViewItem * > top;
+ // restore context
+ while (diff--) {
+ top = istack.top();
+ istack.pop();
+ }
+ parent = top.first;
+ last = top.second;
+ // insert it after the last one we processed
+ if (!parent)
+ item = (last) ? (new
+QListViewItem(dialog_->tree,last)) : (new QListViewItem(dialog_->tree));
+ else
+ item = (last) ? (new QListViewItem(parent,last)) :
+(new QListViewItem(parent));
+ }
+ lyxerr[Debug::GUI] << "Table of contents" << endl << "Added item " <<
+iter->str.c_str()
+ << " at depth " << iter->depth << ", previous sibling \"" <<
+(last ? last->text(0) : "0")
+ << "\", parent \"" << (parent ? parent->text(0) : "0") << "\""
+<< endl;
+ item->setText(0,iter->str.c_str());
+ depth = iter->depth;
+ last = item;
}
- dialog_->tree->setAutoUpdate(true);
+
+ dialog_->tree->setUpdatesEnabled(true);
dialog_->tree->update();
}
@@ -113,15 +157,19 @@
switch (type) {
case Buffer::TOC_TOC:
dialog_->setCaption(_("Table of Contents"));
+ dialog_->tree->setColumnText(0,_("Table of Contents"));
break;
case Buffer::TOC_LOF:
dialog_->setCaption(_("List of Figures"));
+ dialog_->tree->setColumnText(0,_("List of Figures"));
break;
case Buffer::TOC_LOT:
dialog_->setCaption(_("List
NEW_INSETS (was Re: [PATCH] Fix KDE Citation thinko)
On 13 Sep 2000, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On Tue, 12 Sep 2000, John Levon wrote: > | > | > > | > Doh ! > | > > | > (There also seems to a problem with FormToc - namely the list-of-figures > | > from getTocList seems to empty, even when it shouldn't be. Can someone > | > double check it works for xforms/kde, because my older CVS at home doesn't > | > seem to have this problem ... > | > > | > | In fact turning off NEW_INSETS, I don't see a problem, it works fine. Lars > | ? Or is this not supposed to be working yet ? > > NEW_INSETS are supposed to be working (in almost all cases), so it it > doesn't you have found a bug. Please help to fix it. > > Lgb > Lars, the toclist is indeed empty, but I must be being stupid, because the only code I can find that fills up any of these on a getTocList() is Buffer::getTocList() in buffer.C, and with defined NEW_INSETS defined, the only thing that gets added to the list is via line 3751 : l[TOC_TOC].push_back(tmp); So l[TOC_LOF] et al are never filled What am I missing ? thanks john -- "I bet the human brain is a kludge." - Marvin Minsky
Re: dotfill,hrulefill status & open behavior
On 13-Sep-2000 Lars Gullik Bjønnes wrote: > > Is this your code playing tricks on us Jürgen? > Or it is something older/else? I guess this is my code playing tricks :), I will have a look and fix it! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Peace, n.: In international affairs, a period of cheating between two periods of fighting. -- Ambrose Bierce, "The Devil's Dictionary"
Re: InsetRef suggestion: comments please
On 11 Sep 2000, Jean-Marc Lasgouttes wrote: > > "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). I was in fact referring the possibility of just passing an enum as the parameter to a signal. I thought that enum was called status. > Have you ever read LyXFunc::getStatus()? It does exactly that, if I > understand you correctly. Yes but it shouldn't be doing that (menu changes etc.) unless in a gui-indep manner. And then only if it needs to be done. How often does it [de]activate stuff now that isn't visible on the screen and could be checked as its built? IIRC LyXFunc::status was mostly occupied with changing read-only stuff and deciding what output/export stuff should be set to. > 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. If I ever find time I'll rewrite it all the way it should be done ;-) There shouldn't need to be much if any bending. As Marko pointed we could end up with a TOC in a menu, a toolbar and a dialog. They all still need updating. I'd prefer that they were triggered by the same update() signal. A TOC menu that isn't visible, and a dialog that is closed won't be connected to that update signal so we won't be wasting time updating something that the user can't see. The toolbar TOC is likely to be just a copy of the menu TOC (Marko?) so it would only need to be updated when the user opened it (it's not a tearoff as well is it?). A torn-off menu and a dialog would both be connected to the signal and need the same update info. Probably shouldn't pass "section3.1: The new title" that is likely to difficult to do anyway (maybe get away with passing a Paragraph const&), just say "update yourself" instead. So we can at least share the same update signal between the different items. Where do you activate that signal from? We should hopefully only need one or two places in the kernel for any given signal. The cursor movements should only need one place for example. The paragraph update signal could probably be in the same place but with a test to see that we have crossed a paragraph boundary. Triggering an updateTOC signal should be possible from some common area of code -- everything that causes a change to the contents of a paragraph will ask for a redraw of the paragraph won't it? Then put the update signal there with a test to make sure the paragraph would appear in the TOC to avoid unnecessary calls. I'm not sure I like the way this thread is heading -- we could end up with a big ugly mess if we don't try to share more stuff between similar things like menus, toolbars and dialogs. Allan. (ARRae)
Re: [PATCH] KDE FormToc cleanup
On 13-Sep-2000 John Levon wrote: > > Argh, I accidentally sent an old version which won't compile. > Sorry ! New one attached > No problem I read your mail late enough ;) I'll commit this too! NOW: PLEASE make the next patch with the command: cvs diff -N -u >kdewhatever.patch FROM the source root tree (the directory where the Changelog file is). Do you have problems with this? If yes tell me what and we'll see if we can fix them, if not I'll not accept any other patch in any other format! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ With/Without - and who'll deny it's what the fighting's all about? -- Pink Floyd
Re: [PATCH] KDE FormToc cleanup
On 13-Sep-2000 John Levon wrote: > > I should get some sleep :/ I forgot in my former mail: GOOD WORK!!! I like the new look of the KDE-TOC-DIALOG!!! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I have accepted Provolone into my life!
Re: Comments & Notes in LyX
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Why? (some internal comments that should not go to the general Lars> public?) Or some parts of a document you are not sure you want to keep around, and you do not want to have in the LaTeX file (bloat? secret?). Some kind of poor man's version control... I just mentionned that because it is so easy with new insets. JMarc
Re: Internationalisation problem: Turkish i's
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I suspect that we will not have a good solution for this until
Lars> we can begin using Standar C++ locale support and read all files
Lars> with the classic locale ('C')
Easy workaround: lyxlex could use a poor-man ascii-only tolower(),
since keywords should only use [a-zA-Z] (at least they do now).
JMarc
[patch] tracking lists changes, (was InsetRef suggestion ...)
On Wed, 13 Sep 2000, Allan Rae wrote: > There shouldn't need to be much if any bending. As Marko pointed we could > end up with a TOC in a menu, a toolbar and a dialog. They all still need > updating. I'd prefer that they were triggered by the same update() > signal. A TOC menu that isn't visible, and a dialog that is closed won't > be connected to that update signal so we won't be wasting time updating > something that the user can't see. Well. If we don't want to mess with each gui toolkit internals and change the menus only if they are visible then we have to update the status of each menuitem regardless to its visibility. Its the way it is done in gnome frontend and the good news is that it is quite fast (at least I haven't seen any slowdown of LyX due to this constant update). I would expect the same in KDE frontend code. However, we don't have any lists in the menus yet in gnome. > The toolbar TOC is likely to be just a > copy of the menu TOC (Marko?) so it would only need to be updated when the > user opened it (it's not a tearoff as well is it?). A torn-off menu and a > dialog would both be connected to the signal and need the same update > info. Probably shouldn't pass "section3.1: The new title" that is likely > to difficult to do anyway (maybe get away with passing a Paragraph > const&), just say "update yourself" instead. > > So we can at least share the same update signal between the different > items. > > Where do you activate that signal from? We should hopefully only need one > or two places in the kernel for any given signal. The cursor movements > should only need one place for example. The paragraph update signal could > probably be in the same place but with a test to see that we have crossed > a paragraph boundary. Triggering an updateTOC signal should be possible > from some common area of code -- everything that causes a change to the > contents of a paragraph will ask for a redraw of the paragraph won't it? > Then put the update signal there with a test to make sure the paragraph > would appear in the TOC to avoid unnecessary calls. The patch included with this mail adds a new class to src/frontends. This class (ListsTracker, any better name???) keeps the copies of TOC, LOF, LOT, and LOA. If any of this lists changes, the corresponding update signal is emitted. The update signal says just "Update using XXX list" without any specific detail of the change. I've used this class to update FormToc in Gnome frontend and it seems to me that we can remove "Refresh" button in this dialog :). The only problem which I see in current implementation is the place in LyX kernel which should call the ListsTracker update method. I think that this method should be called only if LyX has nothing better to do and only once during this "idle" state. I am not aware know such a nice place in lyx code => it will be nice if someone with better knowledge of lyx internals will find such a place. At present, it is called in LyXView updateToolbar and showState methods (makes lyx reallly slow). Actually, I think we can extend the same technique to track the changes in all LyX actions. However, taking into account that current implementation works quite fast it might be not feesable now. > I'm not sure I like the way this thread is heading -- we could end up with > a big ugly mess if we don't try to share more stuff between similar things > like menus, toolbars and dialogs. to better code? Marko tracker.patch.gz tracker.newfiles.tar.gz
Re: [PATCH] KDE FormToc cleanup
On 13-Sep-2000 John Levon wrote: > > But to do that would require me to have *two* source trees, because cvs > won't know about the new files because I can't do "cvs add". > Well I guess we can add you to the cvs-readonly list AND this means you CAN do an add ;) > just another of those annoying CVS limitations (personally I can't wait > for subversion :) Lars what do you say? Could you also give him write access for the kde frontends? 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ He hath eaten me out of house and home. -- William Shakespeare, "Henry IV"
Re: [PATCH] KDE FormToc cleanup
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 13-Sep-2000 John Levon wrote: | > | > But to do that would require me to have *two* source trees, because cvs | > won't know about the new files because I can't do "cvs add". | > | | Well I guess we can add you to the cvs-readonly list AND this means you | CAN do an add ;) yes. | > just another of those annoying CVS limitations (personally I can't wait | > for subversion :) | | Lars what do you say? Could you also give him write access for the kde | frontends? or only kde? Lgb
Re: lyx-1.1.5fix1 port to OpenBSD
On 13 Sep 2000 09:00:50 +0200, Lars Gullik Bjønnes wrote: >| --- po/Makefile.in.in.orig Tue Sep 12 18:57:02 2000 >| +++ po/Makefile.in.inTue Sep 12 18:51:04 2000 >| @@ -24,6 +24,8 @@ gnulocaledir = $(prefix)/share/locale >| gettextsrcdir = $(prefix)/share/gettext/po >| subdir = po >| >| +DESTDIR = >| + > >Why isn't --prefix enough for you? >Anyway if this is a general problem with the Makefile.in.in in the >gettext, a report should be submitted to the gettex maintainers. I think the OpenBSD-port should only use the native catgets, because this has been security audited and is confirmed to work. GNU gettext is messy, has potential security leaks and doesn't fit well into the system, IMHO. It might even jeopardize the tight overall system security. So it should never be used on any *BSD system. Greets, Arnd
Re: lyx-1.1.5fix1 port to OpenBSD
> "Arnd" == Arnd Hanses <[EMAIL PROTECTED]> writes: Arnd> I think the OpenBSD-port should only use the native catgets, Arnd> because this has been security audited and is confirmed to work. Arnd> GNU gettext is messy, has potential security leaks and doesn't Arnd> fit well into the system, IMHO. It might even jeopardize the Arnd> tight overall system security. So it should never be used on any Arnd> *BSD system. I thought it was only a problem for suid programs... I would not give LyX such special rights, anyway... JMarc
Re: lyx-1.1.5fix1 port to OpenBSD
On 13 Sep 2000, Lars Gullik Bjønnes wrote: > Benjamin Karas <[EMAIL PROTECTED]> writes: > > | Maintained-by: [EMAIL PROTECTED] (David L. Johnson) > > Maintained-by: [EMAIL PROTECTED] (Lars Gullik Bjønnes) and the LyX Team >([EMAIL PROTECTED]) In BSD ports, "Maintained-by" means "who maintais this BSD port", not "who maintains the original software". -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
Re: [PATCH] KDE FormToc cleanup
On 13-Sep-2000 Lars Gullik Bjønnes wrote: > > or only kde? I meant frontends/kde :) 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "The medium is the massage." -- Crazy Nigel
Re: lyx-1.1.5fix1 port to OpenBSD
On Wed, 13 Sep 2000, Arnd Hanses wrote: > I think the OpenBSD-port should only use the native catgets, because > this has been security audited and is confirmed to work. GNU gettext > is messy, has potential security leaks and doesn't fit well into the > system, IMHO. It might even jeopardize the tight overall system > security. So it should never be used on any *BSD system. Have you patched LyX or any other software to use native catgets? In my system (FreeBSD 4.1-RELEASE) I have gettext-0.10.35 installed because it is required by GNU make and wget, but LyX is statically linked to the included gettext. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
Re: lyx-1.1.5fix1 port to OpenBSD
Carlos A M dos Santos <[EMAIL PROTECTED]> writes: | On 13 Sep 2000, Lars Gullik Bjønnes wrote: | | > Benjamin Karas <[EMAIL PROTECTED]> writes: | > | > | Maintained-by: [EMAIL PROTECTED] (David L. Johnson) | > | > Maintained-by: [EMAIL PROTECTED] (Lars Gullik Bjønnes) and the LyX Team |([EMAIL PROTECTED]) | | In BSD ports, "Maintained-by" means "who maintais this BSD port", not "who | maintains the original software". It is still not [EMAIL PROTECTED] Lgb
Re: lyx-1.1.5fix1 port to OpenBSD
On Wed, Sep 13, 2000 at 05:15:17AM +0100, Arnd Hanses wrote: > On 13 Sep 2000 09:00:50 +0200, Lars Gullik Bjønnes wrote: > > >| --- po/Makefile.in.in.orig Tue Sep 12 18:57:02 2000 > >| +++ po/Makefile.in.in Tue Sep 12 18:51:04 2000 > >| @@ -24,6 +24,8 @@ gnulocaledir = $(prefix)/share/locale > >| gettextsrcdir = $(prefix)/share/gettext/po > >| subdir = po > >| > >| +DESTDIR = > >| + > > > >Why isn't --prefix enough for you? > >Anyway if this is a general problem with the Makefile.in.in in the > >gettext, a report should be submitted to the gettex maintainers. [snip] Out of context, but I thought I'd answer this as a debian developer. Yes, this does seem to be an upstream problem with gettext. I don't know if it has ever been reported. 'prefix' isn't good enough because packaging systems (certainly dpkg) have to build into a temporary dir, which is not where the package will run from. If I ./configure --prefix=/home/jules/tmproot/usr, then any embedded paths within the application (in general, possibly not in lyx's case) will be /home/jules/tmproot/usr/bin/appname. So in general debian packaging scripts ./configure --prefix=/usr (so that the paths are correct), but make install DESTDIR=/home/jules/tmproot/ (or whatever). Since gettext doesn't support this, this means that some patch is necessary to it every time ;-( Jules
[Ross Moore <ross@ics.mq.edu.au>] Re: [l2h] newbie, problem with \url + lyx
> I've some documents in: http://www.savebylinux.com/latex/ There are 2 file
> and 2 directory contain HTML result from each file. I use lattest
> latex2html and lyx program. I hope you can explore what's wrong with it.
Thanks.
The fix is very easy:
In the document preamble, just insert the two lines below
beginning with % :
%begin{latexonly}
\IfFileExists{url.sty}{\usepackage{url}}
{\newcommand{\url}{\texttt}}
%end{latexonly}
These "comments" are invisible to LaTeX, but act as environment delimiters
for LaTeX2HTML. The material in-between is filtered out at a very early stage
of processing, hence there can be no incompatibility caused by the
\newcommand{\url}{\texttt}
BTW, (for the Lyx gurus)
would it not be better, partly as a matter of style and efficiency,
to use low-level TeX coding with this conditional code ?
\IfFileExists{url.sty}{\usepackage{url}}{\let\url\texttt}
The reason that LaTeX2HTML has difficulty with a definition such as:
\newcommand{\url}{\texttt}
is that it does not say that (at the user-level) \url should act as if
it takes an argument. When the processor expands macros as in TeX,
then this doesn't matter; but with an alternative expansion model,
it is possible for the \url to get irretrievably separated from its intended
argument. Thus
\newcommand{\url}[1]{\texttt{#1}}
would be a more sympathetic definition for non-TeX,
but the \let version is the most elegent, IMHO.
I hope this provides a complete solution to the compatibility problem.
> Thanks in advances.
You're welcome,
Ross Moore
Re: lyx-1.1.5fix1 port to OpenBSD
On Wed, 13 Sep 2000 10:55:11 + (GMT), Carlos A M dos Santos wrote: >Have you patched LyX or any other software to use native catgets? In my >system (FreeBSD 4.1-RELEASE) I have gettext-0.10.35 installed because it >is required by GNU make and wget, but LyX is statically linked to the >included gettext. Why, you can always simply disable the translations and remove the fn calls. (BTW: The *BSD's are usually employed out of generalized paranoia for special purposes, so normally you would want to avoid the additional complexity of l8n. E.g., OpenBSD has removed nearly all translations from the system, exactly for security reasons.) Greets, Arnd
Re: lyx-1.1.5fix1 port to OpenBSD
On 13 Sep 2000 12:42:49 +0200, Jean-Marc Lasgouttes wrote: > >I thought it was only a problem for suid programs... I would not give >LyX such special rights, anyway... What, if a talented and qualified intrusor would be able to connect the functions to a suid program? This only means that one leak has already been confirmed, there might exist more potential leaks. OpenBSD, on the other hand, is a maximum paranoia system, written for and by insanely paranoid sysadmins. ;-) Greets, Arnd
Re: lyx-1.1.5fix1 port to OpenBSD
On Wed, 13 Sep 2000, Arnd Hanses wrote: > On 13 Sep 2000 12:42:49 +0200, Jean-Marc Lasgouttes wrote: > > > > >I thought it was only a problem for suid programs... I would not give > >LyX such special rights, anyway... > > What, if a talented and qualified intrusor would be able to connect the > functions to a suid program? How would this even be possible ? We are discussing the safety of gettext calls, the only way this could be a problem is if a) someone made LyX suid or b) someone used LyX in a suid app Both are obviously wrong things to do, and neither are open to a malicious hacker ... The only security concerns I can see for LyX is /tmp races if LyX is run as root, or a privileged user of some sort, and the attachment/macro virus stuff, which I believe the interested parties are very very aware of ;) > This only means that one leak has already > been confirmed, there might exist more potential leaks. OpenBSD, on the > other hand, is a maximum paranoia system, written for and by insanely > paranoid sysadmins. ;-) > Some of us have had brushes with Theo before ;) john -- "For every problem there is one solution which is simple, neat, and wrong." - H. L. Mencken
Another apparent problem with NEW_INSETS
With new insets, my FormRef dialog never gets the labels in figure floats that I have in a document (but gets the labels in sections fine). And dispatching a GOTO_REF after explicitly opening up that reference gives the "label not found" error. Lars, I'm sorry I can't debug this further, but I don't have time to work my way round the kernel code right now. If there's anything I can do to help say so thanks john p.s. a quick question, what is the "Name" of a crossref for, and when is it used ? -- "...except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea." - Linus Torvalds
LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000, John Levon wrote: > On Wed, 13 Sep 2000, Arnd Hanses wrote: > > How would this even be possible ? We are discussing the safety of gettext > calls, the only way this could be a problem is if a) someone made LyX suid > or b) someone used LyX in a suid app Or c) user root using LyX. But remember that security also means protecting user privacity. > The only security concerns I can see for LyX is /tmp races if LyX is > run as root, or a privileged user of some sort, and the > attachment/macro virus stuff, which I believe the interested parties > are very very aware of ;) The /tmp races could be avoided by creating a temporary directory, say ~/.lyx/tmp and using it instead of /tmp. I personally dislike the use of a globally writable directory and consider this one of the main flaws in most of the UNIX utilities. Unless I use "umask 077" in my .profile, for example, LyX creates it's temporary files and directories under /tmp with global read permission, so any user in my system can "cd /tmp/lyx_tmp5289aaa/lyx_bufrtmp5289aaa" and read the contents of any file. This may not be good if I'm writing my future plans for total domination. :-) One alternative is install LyX under it's own directory tree by configurin it with "--prefix=/usr/local/lyx" and create a script named /usr/local/bin/lyx containing #!/bin/sh # protect privacity of lyx_tmp* umask 077 exec /usr/local/lyx/bin/lyx "$@" This works well, but has a drawback: all files created LyX will be go-rwx, even those under the home directory. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
Re: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000, Carlos A M dos Santos wrote: > One alternative is install LyX under it's own directory tree by > configurin it with "--prefix=/usr/local/lyx" Or perhaps renaming it /usr/local/bin/lyx.bin. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
RE: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On 13-Sep-2000 Carlos A M dos Santos wrote: > > This works well, but has a drawback: all files created LyX will be go-rwx, > even those under the home directory. Well wouldn't it be easier to specify in the /usr/local/share/lyx/lyxrc file that you want your files in ~/tmp and create a ~/tmp for every user? Or you could just say tempdir=false so it doesn't use any tempdir and let the user specify it own tempdir if (s)he wants it? This are all options you already have with lyx! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You are an insult to my intelligence! I demand that you log off immediately.
Re: new lyx
On Wed, Sep 13, 2000 at 01:27:11PM +1000, Allan Rae wrote: > On Tue, 12 Sep 2000, Amir Karger wrote: > > > OK, so I finally downloaded gcc-2.95.2, so that I could compile the new LyX. > > I assume someone has noted in the requirements that 2.95 no longer works? > > Hint: assume nothing. I kind of figured my assumption was wrong. Creative definition of "assume". > > I assume this is a 2.95.2 thing, not you, since it's coming from the gcc > > stuff. Still, is it there for a reason? > > You missed out the important part: the compilation flags. You'll see that > Lars has set the -Winline flag which is generating all these messages > since gcc can't inline that particular function. IIRC the function in > question is a one-liner but that's not important. Does that mean something could be added to the Makefile to fix the problem? > > Why does nearly every file compilation get this? > > That just shows how many files are dependent upon the use of maps and > other tree based STL containers. Oh, so actually we should be *proud* we're getting so many warnings, because it shows how STL-compliant we are now! -Amir
Re: LyX security (was Re: lyx-1.1.5fix1 port to OpenBSD)
On Wed, 13 Sep 2000, Carlos A M dos Santos wrote: > On Wed, 13 Sep 2000, John Levon wrote: > > > On Wed, 13 Sep 2000, Arnd Hanses wrote: > > > > How would this even be possible ? We are discussing the safety of gettext > > calls, the only way this could be a problem is if a) someone made LyX suid > > or b) someone used LyX in a suid app > > Or c) user root using LyX. how does a malicious user insert dangerous environment variables into root's environment ? I can't see this is an issue. Of course, it's bad practice to run things as run as root unless necessary anyway. > But remember that security also means > protecting user privacity. > of course > > The /tmp races could be avoided by creating a temporary directory, say > ~/.lyx/tmp and using it instead of /tmp. I personally dislike the use of a > globally writable directory and consider this one of the main flaws in > most of the UNIX utilities. > yes, well Juergen has already answered this one ;) john -- "...except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea." - Linus Torvalds
