Re: [Patch] workarea.diff
Andre Poenitz [EMAIL PROTECTED] writes: | This patch makes the work areas (both xforms and qt2) producing directly | FuncRequests for the mouse clicks. For the double and triple clicks I've | introduced new lfuns LFUN_MOUSE_DOUBLE and LFUN_MOUSE_TRIPLE (which btw | would enable insets to handle them, for mathed there is a bug on bugzilla | pending on that...) | | Of course, the actual handling of thes events should be shifted to the | LyXText and Insets eventually, right now I left it in the BufferView do | keep the patch small. | | I think this is conceptually sound, but as it has a bit bigger scope than | yesterdays shift stuff from BufferView_pimpl::dispatch to | LyXText::dispatch I thought I'd better ask. Not too bad. But I feel that the switch/cases are a bit too big and really should be kept in separate functions. Also, one thing I'd really like to see (not necessarily in this patch), is to split the mouse lfuns ... not that is not what I want... I want it to be possible to do a \bind mouse-button-1 place-cursor kindo of binding. This means that the mouse buttons must be seen as a kind of keyboard-key. (keysym if you want) This also implies that there should not be _any_ kind of special LFUNS for mouse handling, but that you use key-bindings to achieve that instead. Then we should not need any kind of special casing in the code on which button was pressed or any explicit mouse button handling at all. FYI: X already has keysyms for these, that we could artificially use if we want to do so: (tripple click is missing) #define XK_Pointer_Left 0xFEE0 #define XK_Pointer_Right0xFEE1 #define XK_Pointer_Up 0xFEE2 #define XK_Pointer_Down 0xFEE3 #define XK_Pointer_UpLeft 0xFEE4 #define XK_Pointer_UpRight 0xFEE5 #define XK_Pointer_DownLeft 0xFEE6 #define XK_Pointer_DownRight0xFEE7 #define XK_Pointer_Button_Dflt 0xFEE8 #define XK_Pointer_Button1 0xFEE9 #define XK_Pointer_Button2 0xFEEA #define XK_Pointer_Button3 0xFEEB #define XK_Pointer_Button4 0xFEEC #define XK_Pointer_Button5 0xFEED #define XK_Pointer_DblClick_Dflt0xFEEE #define XK_Pointer_DblClick10xFEEF #define XK_Pointer_DblClick20xFEF0 #define XK_Pointer_DblClick30xFEF1 #define XK_Pointer_DblClick40xFEF2 #define XK_Pointer_DblClick50xFEF3 #define XK_Pointer_Drag_Dflt0xFEF4 #define XK_Pointer_Drag10xFEF5 #define XK_Pointer_Drag20xFEF6 #define XK_Pointer_Drag30xFEF7 #define XK_Pointer_Drag40xFEF8 #define XK_Pointer_Drag50xFEFD -- Lgb
Qt: dancing ok/apply buttons due to close/cancel swap.
John, I've tested this only in the Graphics dialog, but it may also be in other dialogs: Depending on the something changed state, the bottom right button of the dialog is either [Close] or [Cancel]. The Close string requires less space than the Cancel string and the result is that the [OK] and [Apply] button dance back and forth sideways when the Close is changed to Cancel and vice versa. It's only a tiny thing, but it looks so uggly. Cheers, Rob.
Re: Two graphics layout issues: display mode / subfigure
On Wed, 28 Aug 2002, Rob Lahaye wrote: You don't have the Preferences dialog in Qt yet, but I assume you would like the following: In prefs: o Show in LyX Display: [Mono|Gray|Color] In graph: o Show in LyX Display: [Default|Mono|Gray|Color] Yet, I can't get the logic right. Imagine I have the following settings: In prefs: OFF Show in LyX Display: [whatever] Don't show things... In graph: ON Show in LyX Display: [Default] unless told otherwise by the local graphics setting. This setting for your Qt version does NOT show the image in LyX, irrespective of the graph's Show button ON/OFF setting. No, the local setting overrides the global one. The only problem with this is, should we record in the .lyx file which images were set to be [in]visible by the user in the graphics dialog? Allan. (ARRae)
Re: lyx-devel lib/lyx2lyx/: lyxconvert_215.py
On Wednesday 28 August 2002 06:47, Lars Gullik Bjønnes wrote: Reading a message from Allan it appears that klyx comes with some 2.10 files. | It certainly would not hurt if we could claim compatibility, but I'd find | the possibility of downgrading more important. [Btw: It just occured to | me that downgrading should always be possible as everything unknown to | older versions could be replaced by the ERT flavour of the day...] I already thought about it, but remember ert is evil remember, this ert will depend on the document format: latex, linuxdoc, docbook-sgml, docbook-xml, and will be different for all. We could do it that way... with warnings that information will be lost. To do that in interesting way we should be able, when upgrading, to read ert and if possible convert the new supported structures to the lyx. -- José Abílio
Re: Qt: dancing ok/apply buttons due to close/cancel swap.
On Wed, 28 Aug 2002, R. Lahaye wrote: Depending on the something changed state, the bottom right button of the dialog is either [Close] or [Cancel]. The Close string requires less space than the Cancel string and the result is that the [OK] and [Apply] button dance back and forth sideways when the Close is changed to Cancel and vice versa. Can Qt be tricked by an extra space in Close perhaps? (to fool its too clever auto-geometry code) IIRC, John wants to use Cancel all the time for the Qt frontend. Allan. (ARRae)
Re: [Patch] workarea.diff
On Wed, Aug 28, 2002 at 08:38:39AM +0200, Lars Gullik Bjønnes wrote: Not too bad. But I feel that the switch/cases are a bit too big and really should be kept in separate functions. I said I'll move them down to LyXText (which will make them slimmer). If they are still big than, I'll put them into seperate functions. Certainly today... Also, one thing I'd really like to see (not necessarily in this patch), is to split the mouse lfuns ... not that is not what I want... I want it to be possible to do a \bind mouse-button-1 place-cursor kindo of binding. This means that the mouse buttons must be seen as a kind of keyboard-key. (keysym if you want) Sort of LFUN re-mapping. Should be possible. Actually I like the idea because it makes things more flexible... This also implies that there should not be _any_ kind of special LFUNS for mouse handling, but that you use key-bindings to achieve that instead. Then we should not need any kind of special casing in the code on which button was pressed or any explicit mouse button handling at all. I'd approach this a bit differently. Assume for a while we have inset-local bindings and that lfun re-map feature. The workarea could still generate mouse FuncRequest. After all, the workarea is completely ignorant of text, formulas etc. It only knows it got clicked and has to do something with it. So it passes the mouse lfun to BufferView::dispatch(), and as BufferView is ignorant of this, too, it gets passed in the default branch to LyXText::dispatch(). Now LyXText is the first thing that knows something about text. If the click hits part of the text, the lfun gets LyXText-locally remapped to some set cursor lfun. If the click hits an inset, the FuncRequest is passed on to inset::localDispatch without a change. Now the inset can react to the click by e.g. opening a dialog. If we did a global re-map of mouse-press to cursor-set, the inset would have to react to cursor-set, which is wrong. After all the inset (say InsetRef) does not have to have a cursor at all, and the inset really wants to react to a mouse click and to nothing else. The user might have chosen e.g. to re-map mouse-press to explain-that-thing so suddenly he can't open InsetRefs anymore. Would completely spoil that idea of lfun remapping.. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
John Levon wrote: On Mon, Aug 26, 2002 at 08:53:40AM +0200, Andre Poenitz wrote: Have you tried John's patch from yesterday? It works for me here! No. I've just seen it. Can somebody comment on the table selection bug ? It's a perfect example of the sort of bug that these changes can cause that never get found until freeze time (and inevitably I seem to end sorting out unless Jug finds a spare minute ;) Which bugnumber is this? I don't see such a bug on bugzilla. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: conversion failure with no useful diagnostics
On Wednesday 28 August 2002 00:10, Dr. Richard E. Hawkins wrote: I try to open the attached file, which I used last fall. I am informed that the conversion script failed, with no other diagnostic information. Hi Rick, your document is converted just fine with latest version. I send the result attached. -- José Abílio gametheory.3.lyx.gz Description: GNU Zip compressed data
Re: [Patch] workarea.diff
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, Aug 28, 2002 at 08:38:39AM +0200, Lars Gullik Bjønnes wrote: | Not too bad. But I feel that the switch/cases are a bit too big and | really should be kept in separate functions. | | I said I'll move them down to LyXText (which will make them slimmer). | If they are still big than, I'll put them into seperate functions. | Certainly today... | | Also, one thing I'd really like to see (not necessarily in this | patch), is to split the mouse lfuns ... not that is not what I want... | | I want it to be possible to do a | | \bind mouse-button-1 place-cursor | | kindo of binding. This means that the mouse buttons must be seen as a | kind of keyboard-key. (keysym if you want) | | Sort of LFUN re-mapping. Should be possible. Actually I like the idea | because it makes things more flexible... | | This also implies that there should not be _any_ kind of special LFUNS | for mouse handling, but that you use key-bindings to achieve that | instead. Then we should not need any kind of special casing in the | code on which button was pressed or any explicit mouse button | handling at all. | | I'd approach this a bit differently. Assume for a while we have | inset-local bindings and that lfun re-map feature. | | The workarea could still generate mouse FuncRequest. After all, the | workarea is completely ignorant of text, formulas etc. It only knows it got | clicked and has to do something with it. So it passes the mouse lfun to | BufferView::dispatch(), and as BufferView is ignorant of this, too, it gets | passed in the default branch to LyXText::dispatch(). I do not really agree, and feel that this would be more cleanly supported by context-bindings. But of course if we spread the dispatch out to thin, that will be a real hassle. What I really want is for all dispatch to be really ignorant about mouse buttons. (and the rest of the code as well...) -- Lgb
Re: crash on preview with bad postscript (plan)
R. Lahaye wrote: None of the scripts in lib seem to have the x-bit set? Why is that? They where checked in wrong! Lars could you please set the x-bit directly on the cvs-tree (,v) files as then they are checked out correctly. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [Patch] workarea.diff
On Wed, Aug 28, 2002 at 09:12:54AM +0200, Lars Gullik Bjønnes wrote: What I really want is for all dispatch to be really ignorant about mouse buttons. (and the rest of the code as well...) So how should an inset describe that it wants to popup a dialog on mouse-left? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Two graphics layout issues: display mode / subfigure
Allan Rae wrote: On Wed, 28 Aug 2002, Rob Lahaye wrote: Yet, I can't get the logic right. Imagine I have the following settings: In prefs: OFF Show in LyX Display: [whatever] Don't show things... In graph: ON Show in LyX Display: [Default] unless told otherwise by the local graphics setting. This setting for your Qt version does NOT show the image in LyX, irrespective of the graph's Show button ON/OFF setting. No, the local setting overrides the global one. Can you then tell me what's the point of having a Show check button in the Prefs, if Graph has a Show button that's either On/Off, which ALWAYS overrides the Prefs. There's no point in having a setting in Prefs that's always overriden! Don't tell me to replace the Show check button in Graphs by yet another choice button [on/off/default]; then we would turn the display control into a real beast with bizar logic! I believe there are too many ways of interpreting the display settings with four control widgets (2 in prefs and 2 in graph). Sorry, but apparently I still don't get the logic right :(. Cheers, Rob.
Re: [Patch] workarea.diff
Andre Poenitz [EMAIL PROTECTED] writes: | On Wed, Aug 28, 2002 at 09:12:54AM +0200, Lars Gullik Bjønnes wrote: | What I really want is for all dispatch to be really ignorant about | mouse buttons. (and the rest of the code as well...) | | So how should an inset describe that it wants to popup a dialog on | mouse-left? An inset should never want to popup a dialog on mouse-left, it should only popup a dialog on the LFUN popup-dialog The binding between mouse-button-1 and popup-dialog handle the rest. But to do this we need some kind of context to the bindings. \bind mouse-button-1 cursor-set \global_inset_bind mouse-button-1 popup-dialog -- Lgb
Re: crash on preview with bad postscript (plan)
Juergen Vigna [EMAIL PROTECTED] writes: | R. Lahaye wrote: | None of the scripts in lib seem to have the x-bit set? | Why is that? | | They where checked in wrong! Lars could you please set the | x-bit directly on the cvs-tree (,v) files as then they are | checked out correctly. Please make a list of the files that need this. -- Lgb
Re: Two graphics layout issues: display mode / subfigure
On Wed, 28 Aug 2002, R. Lahaye wrote: No, the local setting overrides the global one. Can you then tell me what's the point of having a Show check button in the Prefs, if Graph has a Show button that's either On/Off, which ALWAYS overrides the Prefs. I just explained what John meant. I'm not sure I like it though. There's no point in having a setting in Prefs that's always overriden! Except if we start out with all the graphics dialogs having the same value as the Prefs and then the user changes one or two on an individual basis. I'll let John argue it out since it's his idea. Allan. (ARRae)
Re: [Patch] workarea.diff
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Andre Poenitz [EMAIL PROTECTED] writes: | | | On Wed, Aug 28, 2002 at 09:12:54AM +0200, Lars Gullik Bjønnes wrote: | | What I really want is for all dispatch to be really ignorant about | | mouse buttons. (and the rest of the code as well...) | | | | So how should an inset describe that it wants to popup a dialog on | | mouse-left? | | An inset should never want to popup a dialog on mouse-left, it should | only popup a dialog on the LFUN popup-dialog | | The binding between mouse-button-1 and popup-dialog handle the | rest. But to do this we need some kind of context to the bindings. | | \bind mouse-button-1 cursor-set | \global_inset_bind mouse-button-1 popup-dialog The problem is of course when and where to lookup the binding. -- Lgb
Re: [Patch] workarea.diff
On Wed, Aug 28, 2002 at 09:36:36AM +0200, Lars Gullik Bjønnes wrote: An inset should never want to popup a dialog on mouse-left, it should only popup a dialog on the LFUN popup-dialog Understood. The binding between mouse-button-1 and popup-dialog handle the rest. But to do this we need some kind of context to the bindings. Right... we don't have that currently, though... So I'd suggest to use the mouse lfuns temporarily (the new ones aren't visible for the user anyway) and change 'case LFUN_MOUSE_PRESS:' to 'case LFUN_DIALOG_POPUP' as soon as the appropriate infra structure is in place. It's trivial then... \bind mouse-button-1 cursor-set \global_inset_bind mouse-button-1 popup-dialog Or maybe \localbind insetname mouse-button-1 popup-dialog with insetname being the inset identifier string that Jean-Marc suggested? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [Patch] workarea.diff
On Wed, Aug 28, 2002 at 09:43:49AM +0200, Lars Gullik Bjønnes wrote: | \bind mouse-button-1 cursor-set | \global_inset_bind mouse-button-1 popup-dialog The problem is of course when and where to lookup the binding. I am not sure. I'd postpone that until we are a bit closer... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
lyx2lyx endless loop
With current cvs I get an endless loop in buffer.C:1185. This goes away if I change the LYX_FORMAT in buffer.C back to 220. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [Patch] workarea.diff
Andre Poenitz [EMAIL PROTECTED] writes: | The binding between mouse-button-1 and popup-dialog handle the | rest. But to do this we need some kind of context to the bindings. | | Right... we don't have that currently, though... So I'd suggest to use the | mouse lfuns temporarily (the new ones aren't visible for the user anyway) | and change 'case LFUN_MOUSE_PRESS:' to 'case LFUN_DIALOG_POPUP' as soon | as the appropriate infra structure is in place. It's trivial then... Yes, I do not expect all to be done at once, but if we have the right solution on the horizon it is easier to pick the small steps that will eventually get us there. | \bind mouse-button-1 cursor-set | \global_inset_bind mouse-button-1 popup-dialog | | Or maybe | | \localbind insetname mouse-button-1 popup-dialog | | with insetname being the inset identifier string that Jean-Marc | suggested? Yes, why not. -- Lgb
Re: crash on preview with bad postscript (plan)
Lars Gullik Bjønnes wrote: Juergen Vigna [EMAIL PROTECTED] writes: | R. Lahaye wrote: | None of the scripts in lib seem to have the x-bit set? | Why is that? | | They where checked in wrong! Lars could you please set the | x-bit directly on the cvs-tree (,v) files as then they are | checked out correctly. Please make a list of the files that need this. Well this should work: chmod a+x /usr/local/lyx/cvsroot/lyx-devel/lib/scripts/* Hope this helps, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: lyx2lyx endless loop
On Wednesday 28 August 2002 08:54, Andre Poenitz wrote: With current cvs I get an endless loop in buffer.C:1185. Could you write the file format to stderr and see what is wrong? That is a little bit above in the same funtion... lyx2lyx is returning the 221 fileformat. The error you describe would happen if lyx2lyx return 220. What does the 40th line of lyx2lyx says? This goes away if I change the LYX_FORMAT in buffer.C back to 220. Andre' -- José Abílio
Re: lyx2lyx endless loop
On Wed, Aug 28, 2002 at 09:24:55AM +0100, José Abílio Oliveira Matos wrote: What does the 40th line of lyx2lyx says? Ah... I was probably only updating in src/... Sorry. Andr'e -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx endless loop
On Wed, Aug 28, 2002 at 09:24:55AM +0100, José Abílio Oliveira Matos wrote: lyx2lyx is returning the 221 fileformat. The error you describe would happen if lyx2lyx return 220. What does the 40th line of lyx2lyx says? Line 40: lst_ft = [210, 215, 216, 217, 218, 220, 221] If no other LyX program is active, please delete the pipe by hand and try again. format: 221 Traceback (most recent call last): File /usr/local/bin/lyx2lyx, line 180, in ? main(sys.argv) File /usr/local/bin/lyx2lyx, line 173, in main __import__(lyxconvert_ + fmt).convert(header,body) File /usr/src/lyx/lyx-devel/lib/lyx2lyx/lyxconvert_220.py, line 78, in convert change_insetgraphics(body) File /usr/src/lyx/lyx-devel/lib/lyx2lyx/lyxconvert_220.py, line 47, in change_insetgraphics size_type = string.split(lines[k])[1] IndexError: list index out of range Bye. -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx endless loop
On Wednesday 28 August 2002 09:26, Andre Poenitz wrote: On Wed, Aug 28, 2002 at 09:24:55AM +0100, José Abílio Oliveira Matos wrote: lyx2lyx is returning the 221 fileformat. The error you describe would happen if lyx2lyx return 220. What does the 40th line of lyx2lyx says? Line 40: lst_ft = [210, 215, 216, 217, 218, 220, 221] Then it is updated. If no other LyX program is active, please delete the pipe by hand and try again. format: 221 Traceback (most recent call last): File /usr/local/bin/lyx2lyx, line 180, in ? main(sys.argv) File /usr/local/bin/lyx2lyx, line 173, in main __import__(lyxconvert_ + fmt).convert(header,body) File /usr/src/lyx/lyx-devel/lib/lyx2lyx/lyxconvert_220.py, line 78, in convert change_insetgraphics(body) File /usr/src/lyx/lyx-devel/lib/lyx2lyx/lyxconvert_220.py, line 47, in change_insetgraphics size_type = string.split(lines[k])[1] IndexError: list index out of range It appears that your graphic does not have neither size_type neither size_kind. Could you send me the offending file, please. :-) Bye. -- José Abílio
Re: lyx2lyx endless loop
On Wed, Aug 28, 2002 at 09:43:47AM +0100, José Abílio Oliveira Matos wrote:
Could you send me the offending file, please. :-)
Sure
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
#LyX 1.3 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass slides
\begin_preamble
\def\head#1{{\large{#1}}}
\pagestyle{empty}
\end_preamble
\options fleqn
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 1
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation skip
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Slide
\layout Standard
\begin_inset ERT
status Collapsed
\layout Standard
{
\backslash
Large
\end_inset
Computing graph invariants
\begin_inset ERT
status Collapsed
\layout Standard
}
\end_inset
\newline
\layout Standard
From edge decomposition formulas
\newline
to composition algorithms
\newline
\layout Standard
\begin_inset Graphics
filename g250_500.eps
lyxscale 70
display monochrome
width 100text%
\end_inset
\layout Standard
André Pönitz
\newline
Hochschule Mittweida
\layout Slide
\layout Standard
\begin_inset ERT
status Collapsed
\layout Standard
\backslash
head{
\end_inset
Edge decomposition formulas
\begin_inset ERT
status Collapsed
\layout Standard
}
\end_inset
\begin_inset Formula \begin{eqnarray*}
R(G) = a(e)\, R(G_{e})+b(e)\, R(G_{-e})\\
R(\overline{K_{n}}) = r(n)\\
r(0) = 1
\end{eqnarray*}
\end_inset
\layout Standard
All-terminal reliability:
\begin_inset Formula \begin{eqnarray*}
R(G) = p_{e}\, R(G_{e})+(1-p_{e})\, R(G_{-e})\\
R(\overline{K_{n}}) = 1_{n\leq 1}
\end{eqnarray*}
\end_inset
Negami polynomial:
\begin_inset Formula \begin{eqnarray*}
N(G) = x\, N(G_{-e})+y\, N(G_{e})\\
N(\overline{K_{n}}) = t^{n}
\end{eqnarray*}
\end_inset
Chromatic polynomial:
\begin_inset Formula \begin{eqnarray*}
\chi (G) = \chi (G_{-e})-\chi (G_{e})\\
\chi (\overline{K_{n}}) = \lambda^{ n}
\end{eqnarray*}
\end_inset
\layout Slide
\layout Standard
\begin_inset ERT
status Collapsed
\layout Standard
\backslash
head{
\end_inset
Trivial algorithm
\begin_inset ERT
status Collapsed
\layout Standard
}
\end_inset
\layout Standard
Repeatedly apply decomposition formula
\layout Standard
\align center
\begin_inset Graphics
filename tree.eps
lyxscale 50
scale 80
\end_inset
\layout Standard
\begin_inset Formula $ O(2^{|E|})$
\end_inset
operations
\layout Slide
\layout Standard
\begin_inset ERT
status Collapsed
\layout Standard
\backslash
head{
\end_inset
\begin_inset ERT
status Collapsed
\layout Standard
}
\end_inset
\layout Standard
Known:
\layout Itemize
polynomial algorithms for
\newline
restricted tree-width
\layout Standard
New:
\layout Itemize
composition algorithms are simple
\layout Itemize
performance not too bad
\layout Itemize
easily constructed
\layout Standard
From decomposition formula we get
\newline
a working
\begin_inset Formula $ O(n\, (m+n)\, (\omega (n)+\log n))$
\end_inset
\newline
within a few minutes.
\layout Standard
An hour of tweaking can reduce that
\newline
by a factor of
\begin_inset Formula $ n$
\end_inset
.
\layout Slide
Algorithm (sketch)
\layout Standard
\begin_inset ERT
status Collapsed
\layout Standard
\backslash
head{
\end_inset
The Algorithm
\begin_inset ERT
status Collapsed
\layout Standard
}
\end_inset
\layout Standard
input
\begin_inset Formula $ G$
\end_inset
\begin_inset Formula $ \ldots $
\end_inset
a graph
\layout Standard
input
\begin_inset Formula $ T$
\end_inset
\begin_inset Formula $ \ldots $
\end_inset
a decomposition formula
\layout Standard
compute composition sequence
\begin_inset Formula $ S$
\end_inset
from
\begin_inset Formula $ G$
\end_inset
\layout Standard
determine transfer function
\begin_inset Formula $ f$
\end_inset
from
\begin_inset Formula $ T$
\end_inset
\layout Standard
set
\begin_inset Formula $ Z_{0}=\{ z_{0}\} $
\end_inset
\layout Standard
for
\begin_inset Formula $ s_{i}\in S$
\end_inset
do
\layout Standard
\begin_inset Formula $ \qquad $
\end_inset
set
\begin_inset Formula $ Z_{i}:=f(s_{i},Z_{i-1})$
\end_inset
\layout Standard
output
\begin_inset Formula $ \textrm{ project}\left(Z_{t}\right)$
\end_inset
\layout Slide
1
\layout Standard
\begin_inset ERT
status Collapsed
\layout Standard
\backslash
head{
\end_inset
Composition Sequences
\begin_inset ERT
status Collapsed
\layout Standard
}
\end_inset
\layout Standard
\begin_inset Formula $ G=(V,E)$
\end_inset
finite, undirected graph
\layout Standard
Re: lyx2lyx endless loop
José Abílio Oliveira Matos wrote: On Wednesday 28 August 2002 09:26, Andre Poenitz wrote: Line 40: lst_ft = [210, 215, 216, 217, 218, 220, 221] Then it is updated. It appears that your graphic does not have neither size_type neither size_kind. I think I know what's going on: There was a small time gap of a day or two (or even more) between the introduction by me of the new graphics layout, and the increment of the lyx-format to 221. It consisted of two separate patches, one was applied immediately, the other after some discussion! During that time, lyx-cvs was writing graphics insets with the new format, but under 220 version number. That can be the reason why the old version number with new layout (missing size_kind/type) is there. So the reason Andre has trouble with file conversion, may be because his file was generated in that small time gap. A simply hack would be to manually edit the file and change the format from 220 into 221; save it and reload in LyX. Does that help? Regards, Rob.
Re: lyx2lyx endless loop
Andre Poenitz wrote: #LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 220 [...] \begin_inset Graphics filename g250_500.eps lyxscale 70 display monochrome width 100text% \end_inset Yep, Andre you are using a version of LyX that is build inbetween two of my patches. My first patch introduced the new graphics inset layout, the second one incremented the lyxformat to 221. Simply change 220 into 221 and reload in LyX, should do the trick. PLEASE NOTE: this is NEITHER a bug in LyX NOR in lyx2lyx. This only occurs for those lyx files that are saved by the cvs version built inbetween my two patches. Sorry for the inconvenience. Rob.
Re: factory patch
Andre == Andre Poenitz [EMAIL PROTECTED] writes: This way, there would be no need for an hardcoded list of inset codes in inset.h. And the autoregistration code would have a table of existing insets, maybe with some entry points for creating a new inset of this type. Andre Ok. But certain insets would still need certain additional data Andre be passed on creation, and for auto-registration we'd need a Andre uniform constructor for all insets which takes that data.. Yes, maybe... JMarc
Re: New default.ui menu (the right one)
Dekel == Dekel Tsur [EMAIL PROTECTED] writes: Dekel On Tue, Aug 27, 2002 at 05:32:18PM +0200, Jean-Marc Lasgouttes Dekel wrote: Maybe it would be better to use a different mechanism Dekel for errors: If there are latex errors, we open a dialog that Dekel lists all the errors in the document, and clicking on an entry Dekel moves to the corresponding position in the LyX file. And what if one has moved things around after running latex? Dekel Usually, the changes you do after latex errors are minor Dekel (fixing typos in the command names etc.) Yes, usually. But we have to make sure that lyx does something sensible when people do unusual things. JMarc
Re: lyx2lyx endless loop
On Wed, Aug 28, 2002 at 05:55:27PM +0900, R. Lahaye wrote: So the reason Andre has trouble with file conversion, may be because his file was generated in that small time gap. As we are talking abount my current real work, this is quite probable. A simply hack would be to manually edit the file and change the format from 220 into 221; save it and reload in LyX. Does that help? Yes. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx2lyx endless loop
On Wed, Aug 28, 2002 at 05:55:27PM +0900, R. Lahaye wrote: It appears that your graphic does not have neither size_type neither size_kind. During that time, lyx-cvs was writing graphics insets with the new format, but under 220 version number. That can be the reason why the old version number with new layout (missing size_kind/type) is there. I just committed a fix for this.
Re: lyx2lyx endless loop
On Wed, Aug 28, 2002 at 06:00:18PM +0900, R. Lahaye wrote: Sorry for the inconvenience. No problem. There are worse things than that. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: more on File menu for a single entry?
John == John Levon [EMAIL PROTECTED] writes: John On Tue, Aug 27, 2002 at 12:32:09PM -0400, Dr. Richard E. Hawkins John wrote: I just got a more for the last entry on File--clicking on it showed a single entry. That is, the more was only to get to the entry that should have been it its place. John I don't understand, how is our menu deciding to add More... John *at all* ? I've never seen such behaviour... It is an idea of mine :) When moving the toc code out of the xforms frontend, I decided that the code that added 'More...' for long menus could better be used in the generic case. The menu length can be increased with constant max_number_of_items oor something like that. This is frontend-specific, as I guess qt has its own mechanism for dealing with long menus. What I can do is: 1/ avoid the stupid situation reported by hawk 2/ increase the constant, which is currently 25. What would be a good number? JMarc
Re: lyx-devel src/: BufferView_pimpl.C BufferView_pimpl.h text3.C
On Wed, Aug 28, 2002 at 11:06:23AM +0200, Jean-Marc Lasgouttes wrote: Would you care repeating the details a bit? Like that? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson) Index: BufferView_pimpl.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v retrieving revision 1.238.2.5 diff -u -p -r1.238.2.5 BufferView_pimpl.C --- BufferView_pimpl.C 21 Aug 2002 19:03:10 - 1.238.2.5 +++ BufferView_pimpl.C 28 Aug 2002 09:12:53 - -3013,8 +3013,7 bool BufferView::Pimpl::Dispatch(kb_acti new InsetTabular(*buffer_, r, c); bool const rtl = bv_-getLyXText()-real_current_font.isRightToLeft(); - if (!open_new_inset(new_inset, rtl)) - delete new_inset; + open_new_inset(new_inset, rtl); } break;
Re: lyx-devel lib/lyx2lyx/: lyxconvert_215.py
On Wed, Aug 28, 2002 at 11:14:03AM +0200, Jean-Marc Lasgouttes wrote: Andre My oldest docs are 2.15, so I have no real personal interest. Andre But what does klyx produce? Shouldn't that be around 0.10? Yes, supporting klyx format is important, if we want it to definitely die. And I think klyx has basically 0.12.1 format. I had a look, there are two files with 0.10, the rest is 0.12 in the klyx distribution. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: lyx-devel lib/lyx2lyx/: lyxconvert_215.py
On Wednesday 28 August 2002 10:13, Andre Poenitz wrote: On Wed, Aug 28, 2002 at 11:14:03AM +0200, Jean-Marc Lasgouttes wrote: Andre My oldest docs are 2.15, so I have no real personal interest. Andre But what does klyx produce? Shouldn't that be around 0.10? Yes, supporting klyx format is important, if we want it to definitely die. And I think klyx has basically 0.12.1 format. I had a look, there are two files with 0.10, the rest is 0.12 in the klyx distribution. Since I have already an half working convertion I will go the full path, and stop (for now). It would be fun, for 1.4 to have total backward compatibility. As the warning that appears regarding fileformat 200: Old LyX file format found. Use LyX 0.10.x to read this! although true is not realistic. It is impossible to find an 0.8[16] xforms version compiled for present systems. Backward compatibility is also a 1.4 project for me. Andre' -- José Abílio
Re: New default.ui menu (the right one)
On Wed, Aug 28, 2002 at 11:05:00AM +0200, Jean-Marc Lasgouttes wrote: Dekel On Tue, Aug 27, 2002 at 05:32:18PM +0200, Jean-Marc Lasgouttes Dekel wrote: Maybe it would be better to use a different mechanism Dekel for errors: If there are latex errors, we open a dialog that Dekel lists all the errors in the document, and clicking on an entry Dekel moves to the corresponding position in the LyX file. And what if one has moved things around after running latex? Dekel Usually, the changes you do after latex errors are minor Dekel (fixing typos in the command names etc.) Yes, usually. But we have to make sure that lyx does something sensible when people do unusual things. It is not a big problem. The interface has the following advantages over the current one: - Simpler code - You do not need to click on each error inset in order to see the error message - You can view all error messages at one, so if they all have the same cause (e.g. forgetting to include a package) then you do not need to go to each individual error
Re: lyx-devel src/: BufferView_pimpl.C BufferView_pimpl.h text3.C
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Wed, Aug 28, 2002 at 11:06:23AM +0200, Jean-Marc Lasgouttes Andre wrote: Would you care repeating the details a bit? Andre Like that? Yes, thanks. JMarc
Re: New default.ui menu (the right one)
Dekel == Dekel Tsur [EMAIL PROTECTED] writes: Dekel It is not a big problem. Dekel The interface has the following advantages over the current Dekel one: - Simpler code - You do not need to click on each error Dekel inset in order to see the error message - You can view all Dekel error messages at one, so if they all have the same cause (e.g. Dekel forgetting to include a package) then you do not need to go to Dekel each individual error Agreed. Getting rid of this awful error insets would be a very good thing, I think. JMarc
Re: save as dialog flashes without being read.
Richard == Richard E Hawkins [EMAIL PROTECTED] writes: Richard If I double click on the name of anther file using save-as, Richard nothing happens. If I triple click, a dialog pops up, which I Richard think has a warning symbol, but whatever it is comes and goes Richard too quickly to see what it is. I am not sure we can do much about that. I suspect this is xforms fault. JMarc
Re: lyx-devel src/frontends/qt2/: ChangeLog Makefile.am Menubar_pi ...
John == John Levon [EMAIL PROTECTED] writes: John On Tue, Aug 27, 2002 at 12:28:49PM +0200, Jean-Marc Lasgouttes John wrote: I knew it would :) John Except : John 1) Navigate is not parsed. I thought I would not need extra code John dealing with it ? Could you elaborate? Is it the only thing that does not work. From a cursory look, your code seems correct. John 2) Navigate crashes with big documents. Related perhaps ? Don't know. JMarc
Xforms: bug in fdesign or what?
Hi, I'm sorry to bother you here about this, but I'm not expecting much from the Xforms mailing list. I tried to optimize the layout of a few Xforms dialogs using fdesign, until I realized that fdesign ignores the settings of NW Gravity, SE Gravity and Resize in the Attributes. Whenever I open the attributes of a widget (I may or may not change one of the above mentioned fields), Gravity and Resize is always reset to NoGravity and RESIZE_NONE. fdesign does not allow resizing of your choice with the proper gravity. Is this a bug in fdesign or am I doing something wrong? BTW: using fdesign in the Makefile with fdesign -convert does not alter these values. It happens only when running the X-app. and open the Attributes dialog. I'm using Xforms 1.0.0. Thanks, Rob. PS: I myself find all the Xforms dialog far too bulky, especially when compared to their Qt counterparts. Downsizing the height of the widgets is needed. Making default height 25, instead of 30 already helps a lot. In the meantime I would like do the Resize and Gravity properly, but fdesign doesn't seem to allow me :(.
Re: bug 490 - comments ?
John Levon wrote:
There is a problem with Layout/Document/Paper settings:
If I leave the headheight, headsep, footskip empty, I would assume they
are
zero. But they are by default NOT! I do not know the default values.
[snip]
This is a bug. It applies also to the custom margins. If the fields are empty,
then the default margins from geometry are used, which are not 0, but 0
will be read in as empty field. So it's a rather grave bug.
AFAICS, the bug is in xforms_helpers.C (void updateWidgetsFromLength), line
155 (len.zero()):
if (len.zero()) {
fl_set_input(input, );
fl_set_choice_text(choice, default_unit.c_str());
} else {
ostringstream buffer;
buffer len.value();
fl_set_input(input, buffer.str().c_str());
// Set the choice to the desired unit, if present in the choice.
// Else set the choice to the default unit.
string const unit = subst(stringFromUnit(len.unit()),%,%%);
vectorstring const vec = getVector(choice);
vectorstring::const_iterator it =
std::find(vec.begin(), vec.end(), unit);
if (it != vec.end()) {
fl_set_choice_text(choice, unit.c_str());
} else {
fl_set_choice_text(choice, default_unit.c_str());
}
}
Obviously, len.zero() does not make a difference between values with 0 and
empty values. This has to be changed. I'm shure it is easy, but I don't know
how. Any hints?
Thanks,
Jürgen.
[jamatos@novalis.fc.up.pt: Re: conversion failure with no useful diagnostics]
- Forwarded message from Jos? Ab?lio Oliveira Matos [EMAIL PROTECTED] - From: Jos? Ab?lio Oliveira Matos [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: conversion failure with no useful diagnostics Date: Wed, 28 Aug 2002 08:17:46 +0100 On Wednesday 28 August 2002 00:10, Dr. Richard E. Hawkins wrote: I try to open the attached file, which I used last fall. I am informed that the conversion script failed, with no other diagnostic information. Hi Rick, your document is converted just fine with latest version. I send the result attached. Thanks. But how much later can your version be; mine was less than an hour old . . . I converted by installing the FreeBSD port, which uses (I presume) the last regular release, and saving the file, then returning to my cvs version . . . hawk
Re: more on File menu for a single entry?
On Wed, Aug 28, 2002 at 11:12:20AM +0200, Jean-Marc Lasgouttes wrote: John == John Levon [EMAIL PROTECTED] writes: 2/ increase the constant, which is currently 25. What would be a good number? I see 20 + the more. I don't suppose it can be based on window height? If the console version were ever to appear, the limit would be about 20, For my monster screen, I'd say 50 . . . hawk
Re: save as dialog flashes without being read.
On Wed, Aug 28, 2002 at 12:27:32PM +0200, Jean-Marc Lasgouttes wrote: Richard == Richard E Hawkins [EMAIL PROTECTED] writes: Richard If I double click on the name of anther file using save-as, Richard nothing happens. If I triple click, a dialog pops up, which I Richard think has a warning symbol, but whatever it is comes and goes Richard too quickly to see what it is. I am not sure we can do much about that. I suspect this is xforms fault. But what *should* be happening? I assume that that dialog must come from lyx in some manner . . . hawk
Re: conversion failure with no useful diagnostics
On Wed, Aug 28, 2002 at 07:17:18AM -0400, Dr. Richard E. Hawkins wrote: your document is converted just fine with latest version. I send the result attached. Thanks. But how much later can your version be; mine was less than an hour old . . . I converted by installing the FreeBSD port, which uses (I presume) the last regular release, and saving the file, then returning to my cvs version . . . Is the lyx2lyx script in your execution path ?
Re: Buf in lyxconvert_217.py
On Wednesday 28 August 2002 12:38, Dekel Tsur wrote: In update_tabular, the line i = i + len(new_table) causes the conversion to ignore nested tabulars. Ok, do you have any example at hand, that you could send me. The table is enough. -- José Abílio
Re: New default.ui menu (the right one)
Jean-Marc Lasgouttes wrote: Dekel The interface has the following advantages over the current Dekel one: - Simpler code - You do not need to click on each error Dekel inset in order to see the error message - You can view all Dekel error messages at one, so if they all have the same cause (e.g. Dekel forgetting to include a package) then you do not need to go to Dekel each individual error Agreed. Getting rid of this awful error insets would be a very good thing, I think. I also agree completely with this! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Bug in lyxconvert_217.py
On Wed, Aug 28, 2002 at 12:50:01PM +0100, José Abílio Oliveira Matos wrote: On Wednesday 28 August 2002 12:38, Dekel Tsur wrote: In update_tabular, the line i = i + len(new_table) causes the conversion to ignore nested tabulars. Ok, do you have any example at hand, that you could send me. The table is enough. I don't have a LyX executable that generates the 2.17 format. Just create a tabular, and put a tabular in the 1st cell of the first tabular. BTW, I think that just using i=i+1 will solve the bug.
Re: lyx-devel src/frontends/qt2/: ChangeLog Makefile.am Menubar_pi...
Jean-Marc Lasgouttes wrote: John 2) Navigate crashes with big documents. Related perhaps ? Don't know. Maybe the same problem xforms had with menus which where too large? (too many entries). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: bug 490 - comments ?
Juergen Spitzmueller wrote: John Levon wrote: There is a problem with Layout/Document/Paper settings: If I leave the headheight, headsep, footskip empty, I would assume they are zero. But they are by default NOT! I do not know the default values. [snip] This is a bug. It applies also to the custom margins. If the fields are empty, then the default margins from geometry are used, which are not 0, but 0 will be read in as empty field. So it's a rather grave bug. AFAICS, the bug is in xforms_helpers.C (void updateWidgetsFromLength), line 155 (len.zero()): I was actually struggling with the same problem while modifying the graphics dialog. LyXLength could be augmented with a private member bool empty, that is only TRUE in case of an empty-string input field. In stead of testing if (len.zero()), we should then test if (len.empty()). The len.zero() is obsolete and the value zero should be treated just as any other value. Cheers, Rob.
Re: New default.ui menu (the right one)
Juergen Vigna [EMAIL PROTECTED] writes: | Jean-Marc Lasgouttes wrote: Dekel The interface has the following advantages over the current Dekel one: - Simpler code - You do not need to click on each error Dekel inset in order to see the error message - You can view all Dekel error messages at one, so if they all have the same cause (e.g. Dekel forgetting to include a package) then you do not need to go to Dekel each individual error Agreed. Getting rid of this awful error insets would be a very good thing, I think. | I also agree completely with this! I agree. -- Lgb
Re: Xforms: bug in fdesign or what?
R == R Lahaye [EMAIL PROTECTED] writes: R Hi, R I'm sorry to bother you here about this, but I'm not expecting much R from the Xforms mailing list. R I tried to optimize the layout of a few Xforms dialogs using R fdesign, until I realized that fdesign ignores the settings of NW R Gravity, SE Gravity and Resize in the Attributes. R Whenever I open the attributes of a widget (I may or may not change R one of the above mentioned fields), Gravity and Resize is always R reset to NoGravity and RESIZE_NONE. R fdesign does not allow resizing of your choice with the proper R gravity. R Is this a bug in fdesign or am I doing something wrong? I have to admit that I do not know. R PS: I myself find all the Xforms dialog far too bulky, especially R when compared to their Qt counterparts. Downsizing the height of R the widgets is needed. Making default height 25, instead of 30 R already helps a lot. One thing you should be careful about is the lenght of texts. Translations like german have much longer strings, so you should reserve room for that. JMarc
Re: Xforms: bug in fdesign or what?
Jean-Marc Lasgouttes wrote: R == R Lahaye [EMAIL PROTECTED] writes: R fdesign does not allow resizing of your choice with the proper R gravity. R Is this a bug in fdesign or am I doing something wrong? I have to admit that I do not know. I wonder if any LyX Xforms designer has ever bothered to get this right. Please speak up, if you have. Maybe it once worked with earlier versions of fdesign; but I truely believe fdesign that comes with 1.0.0 is broken for this purpose. R PS: I myself find all the Xforms dialog far too bulky, especially R when compared to their Qt counterparts. Downsizing the height of R the widgets is needed. Making default height 25, instead of 30 R already helps a lot. One thing you should be careful about is the lenght of texts. Translations like german have much longer strings, so you should reserve room for that. I'm talking about reducing the height, not the width. The text would still fit in, unless the german font is twice as large :) Anyway, I need first a properly working fdesign for this operation! Cheers, Rob.
Re: conversion failure with no useful diagnostics
On Wed, Aug 28, 2002 at 02:34:41PM +0300, Dekel Tsur wrote: Is the lyx2lyx script in your execution path ? slytherinttyp1:hawkwhich lyx2lyx lyx2lyx: Command not found. Nope; apparently not. But isn't this something lyx should be taking care of, rather than the user? hawk -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
Re: conversion failure with no useful diagnostics
Richard == Richard E Hawkins [EMAIL PROTECTED] writes: Richard On Wed, Aug 28, 2002 at 02:34:41PM +0300, Dekel Tsur wrote: Is the lyx2lyx script in your execution path ? Richard slytherinttyp1:hawkwhich lyx2lyx lyx2lyx: Command not found. Richard Nope; apparently not. But isn't this something lyx should be Richard taking care of, rather than the user? Yes. In the meantime, you can do a symbolic link. JMarc
Re: Xforms: bug in fdesign or what?
Rob == Rob Lahaye [EMAIL PROTECTED] writes: Rob Jean-Marc Lasgouttes wrote: R == R Lahaye [EMAIL PROTECTED] writes: R fdesign does not allow resizing of your choice with the proper R gravity. Is this a bug in fdesign or am I doing something wrong? I have to admit that I do not know. Rob I wonder if any LyX Xforms designer has ever bothered to get this Rob right. Please speak up, if you have. Maybe it once worked with Rob earlier versions of fdesign; but I truely believe fdesign that Rob comes with 1.0.0 is broken for this purpose. I can confirm this bug. I took a brief look at fdesign source but could not find anything obvious. I sent a message about it to the xforms list (just in case). Maybe is it necessary to use an older fdesign (like from 0.89.6). Rob I'm talking about reducing the height, not the width. The text Rob would still fit in, unless the german font is twice as large :) Rob Anyway, I need first a properly working fdesign for this Rob operation! I just wanted to make sure... :) JMarc
Re: Xforms: bug in fdesign or what?
Jean-Marc Lasgouttes wrote: I can confirm this bug. I took a brief look at fdesign source but could not find anything obvious. I sent a message about it to the xforms list (just in case). Maybe is it necessary to use an older fdesign (like from 0.89.6). No I'm rather not go back to old Xforms. I'll keep my fingers crossed that your report to the list will fix fdesign in 1.0.0rc5. Lot's of other stuff to do. Cheers, Rob.
gee, SpamAssassin flagged my bug report
For others that are as easily ammused as I am, I'm including spam assassin's tagging of my bug report. Real spam rarely hits 7.3 . . . On Tue, Aug 27, 2002 at 02:12:51PM -0400, Dr. Richard E. Hawkins wrote: SPAM: Start SpamAssassin results -- SPAM: This mail is probably spam. The original message has been altered SPAM: so you can recognise or block similar unwanted mail in future. SPAM: See http://spamassassin.org/tag/ for more details. SPAM: SPAM: Content analysis details: (7.3 hits, 5 required) SPAM: CALL_NOW (4.7 points) BODY: Urges you to call now SPAM: WEIRD_PORT (0.3 points) URI: Uses non-standard port number for HTTP SPAM: PORN_3 (0.5 points) Uses words and phrases which indicate porn (3) SPAM: NO_MX_FOR_FROM (1.8 points) No MX records for the From: domain SPAM: SPAM: End of SpamAssassin results - gdb output and included files snipped
Re: Xforms: bug in fdesign or what?
Rob == Rob Lahaye [EMAIL PROTECTED] writes: Rob Jean-Marc Lasgouttes wrote: I can confirm this bug. I took a brief look at fdesign source but could not find anything obvious. I sent a message about it to the xforms list (just in case). Maybe is it necessary to use an older fdesign (like from 0.89.6). Rob No I'm rather not go back to old Xforms. I'll keep my fingers Rob crossed that your report to the list will fix fdesign in Rob 1.0.0rc5. Lot's of other stuff to do. I decided to take an harder look and fixed the bug. It was a rather stupid one :) If you can compile fdesign yourself, here is the patch. I will send it to the xforms list. JMarc --- fdesign/fd_attribs.c.orig Wed Aug 28 15:24:59 2002 +++ fdesign/fd_attribs.c Wed Aug 28 15:25:41 2002 @@ -305,15 +305,15 @@ else obj-align = ~FL_ALIGN_INSIDE; -snprintf(tmpbuf,sizeof(tmpbuf),FL_, +snprintf(tmpbuf,sizeof(tmpbuf),FL_%s, fl_get_choice_text(fd_generic_attrib-resize)); obj-resize = resize_val(tmpbuf); -snprintf(tmpbuf,sizeof(tmpbuf),FL_, +snprintf(tmpbuf,sizeof(tmpbuf),FL_%s, fl_get_choice_text(fd_generic_attrib-segravity)); obj-segravity = gravity_val(tmpbuf); -snprintf(tmpbuf,sizeof(tmpbuf),FL_, +snprintf(tmpbuf,sizeof(tmpbuf),FL_%s, fl_get_choice_text(fd_generic_attrib-nwgravity)); obj-nwgravity = gravity_val(tmpbuf);
Re: lyx-devel lib/lyx2lyx/: lyxconvert_217.py
On Wed, Aug 28, 2002 at 02:37:34PM +0100, José Abílio Oliveira Matos wrote: Log message: Don't use .extend() (doesn't work in python 1.5) Why? Extend really works with 1.5.2 that should be our target. It doesn't work with 1.5.1 The code you have now will not work, because of the scope declaration, lines is declared inside the function so will not be returned. I've noticed that and committed a fix. Now, I use lines[i:j] = new_table (which is shorter than the .extend code)
Re: lyx-devel lib/lyx2lyx/: lyxconvert_217.py
On Wednesday 28 August 2002 14:40, Dekel Tsur wrote: On Wed, Aug 28, 2002 at 02:37:34PM +0100, José Abílio Oliveira Matos wrote: Log message: Don't use .extend() (doesn't work in python 1.5) Why? Extend really works with 1.5.2 that should be our target. It doesn't work with 1.5.1 We should require 1.5.2 that should be our minimum. If we could use 2.2 we would be able to reduce the code by 1/3 at least. :-) The code you have now will not work, because of the scope declaration, lines is declared inside the function so will not be returned. I've noticed that and committed a fix. Now, I use lines[i:j] = new_table (which is shorter than the .extend code) Ok, this is a better idiom, and a lot easier to read and see what is going on. :-) -- José Abílio
[PATCH] GraphicsConverter: do not use ChangeExtension
In Lyx 1.2.2 CVS, GraphicsConvert.C:113 you do not use
ChangeExtension.
The same problem may arise in GConverter::build_script, few lines later.
The attached files trigger the problem.
Regards,
Marco Morandini
RCS file: /cvs/lyx/lyx-devel/src/graphics/GraphicsConverter.C,v
retrieving revision 1.4.2.1
diff -u -r1.4.2.1 GraphicsConverter.C
--- src/graphics/GraphicsConverter.C2002/07/01 14:51:03 1.4.2.1
+++ src/graphics/GraphicsConverter.C2002/08/28 14:42:29
-163,8 +163,10
{
typedef Converters::EdgePath EdgePath;
- string const to_file = ChangeExtension(to_file_base,
-
formats.extension(to_format));
+ // We do not use ChangeExtension here because this is a
+ // basename, which may nevertheless contain a dot
+ string const to_file =
+ to_file_base + '.' + formats.extension(to_format);
if (from_format == to_format) {
script move_file(QuoteName(from_file),
QuoteName(to_file));
pippo.tgz
Description: GNU Unix tar archive
Re: Bug in lyxconvert_217.py
On Wednesday 28 August 2002 12:52, Dekel Tsur wrote: I don't have a LyX executable that generates the 2.17 format. I do so I will take care of that. Just create a tabular, and put a tabular in the 1st cell of the first tabular. BTW, I think that just using i=i+1 will solve the bug. No it doesn't because the table will be wrong since we are catching the end of the nested table and not the end of the first table. So I can catch the nested table inside and then apply the transformation to it. -- José Abílio
Re: undo's kill lyx
On Tue, Aug 27, 2002 at 06:23:57PM -0400, Dr. Richard E. Hawkins wrote: I made a bunch of changes, realized it was the wrong file, and held down ^Z. At the very least we need a backtrace. A way to reproduce is usually necessary for the undo stuff too :/ We have one known undo problem on bugzilla, it may be that regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: lyx-devel lib/lyx2lyx/: lyxconvert_215.py
On Wed, Aug 28, 2002 at 10:31:33AM +0100, José Abílio Oliveira Matos wrote: although true is not realistic. It is impossible to find an 0.8[16] xforms version compiled for present systems. With a little hacking it is possible to get the oldest lyx version of ftp.lyx.org to compile and hobble along... regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Wed, Aug 28, 2002 at 06:04:30AM +0200, Andre Poenitz wrote: Have you tried John's patch from yesterday? It works for me here! No. I've just seen it. Can somebody comment on the table selection bug ? Which one? The mouse click stuff was fixed AFAIK. Enter some text in a table cell. Now select another cell (cell selection not insettext selection). Now click in the middle of the text in the other table cell -there is a selection in the text, wrongly I mentioned it in this thread somewhere (there's no bug nr. yet, as I asked if it's not obvious then I'll open a bug) It's a perfect example of the sort of bug that these changes can cause that never get found until freeze time (and inevitably I seem to end sorting out unless Jug finds a spare minute ;) I have the impression that things are currently improving in that area... This does not necessarily mean less obvious bugs but rather less bugs, most of them easily fixable. Fiable for who ? e.g. the cannot click to the right of insets in 1.2.0cvs, probably easy for Jug etc. but took me hours to fix :/ regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: undo's kill lyx
John == John Levon [EMAIL PROTECTED] writes: John On Tue, Aug 27, 2002 at 06:23:57PM -0400, Dr. Richard E. Hawkins John wrote: I made a bunch of changes, realized it was the wrong file, and held down ^Z. John At the very least we need a backtrace. A way to reproduce is John usually necessary for the undo stuff too :/ John We have one known undo problem on bugzilla, it may be that I think we have had several reports about undo (some of the recent bugs from MIchael). There is probably a bad undo bug somewhere. JMarc
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
John Levon wrote: Enter some text in a table cell. Now select another cell (cell selection not insettext selection). Now click in the middle of the text in the other table cell -there is a selection in the text, wrongly I mentioned it in this thread somewhere (there's no bug nr. yet, as I asked if it's not obvious then I'll open a bug) This should be easy to fix IMO. I'll have a look tomorrow. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Two graphics layout issues: display mode / subfigure
On Wed, Aug 28, 2002 at 03:02:36PM +0900, Rob Lahaye wrote: Yet, I can't get the logic right. Imagine I have the following settings: In prefs: OFF Show in LyX Display: [whatever] In graph: ON Show in LyX Display: [Default] This setting for your Qt version does NOT show the image in LyX, irrespective of the graph's Show button ON/OFF setting. Yes, good point. I'll have to think about this some more. The simplest option is probably to remove Default when the system setting is to not show. regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: lyx-devel lib/lyx2lyx/: lyxconvert_215.py
On Wednesday 28 August 2002 16:33, John Levon wrote: On Wed, Aug 28, 2002 at 10:31:33AM +0100, José Abílio Oliveira Matos wrote: although true is not realistic. It is impossible to find an 0.8[16] xforms version compiled for present systems. With a little hacking it is possible to get the oldest lyx version of ftp.lyx.org to compile and hobble along... Yes. I have done that until 0.10.7. For that version I have to install xforms 0.86. All others (including 1.2.1) can compile with 0.88. So my problem is 0.10.7, not all the others. :-) And even for 0.10.7 the code should be easy to compile the problems is xforms. Ditto for still older versions... regards john -- José Abílio
Re: Qt: dancing ok/apply buttons due to close/cancel swap.
On Wed, Aug 28, 2002 at 04:58:59PM +1000, Allan Rae wrote: On Wed, 28 Aug 2002, R. Lahaye wrote: Depending on the something changed state, the bottom right button of the dialog is either [Close] or [Cancel]. The Close string requires less space than the Cancel string and the result is that the [OK] and [Apply] button dance back and forth sideways when the Close is changed to Cancel and vice versa. Can Qt be tricked by an extra space in Close perhaps? (to fool its too clever auto-geometry code) Not really. Thing is, something changed in Qt Designer, and it's really hard to get the right behaviour now. It used to work OK. And yes, Rob, it's a real problem that I know about, but it's mega-low priority right now. IIRC, John wants to use Cancel all the time for the Qt frontend. I think that was just something I said a long time ago ... regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: more on File menu for a single entry?
On Wed, Aug 28, 2002 at 11:12:20AM +0200, Jean-Marc Lasgouttes wrote: It is an idea of mine :) When moving the toc code out of the xforms frontend, I decided that the code that added 'More...' for long menus could better be used in the generic case. The menu length can be increased with constant max_number_of_items oor something like that. This is frontend-specific, as I guess qt has its own mechanism for dealing with long menus. Ah right. What I can do is: 1/ avoid the stupid situation reported by hawk How did it ever happen with File anyway ? Surely it only applies to Navigate menu. 2/ increase the constant, which is currently 25. What would be a good number? Don't do this, that's a LOT already :) regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: lyx-devel src/frontends/qt2/: ChangeLog Makefile.am Menubar_pi ...
On Wed, Aug 28, 2002 at 12:31:22PM +0200, Jean-Marc Lasgouttes wrote: John 1) Navigate is not parsed. I thought I would not need extra code John dealing with it ? Could you elaborate? Is it the only thing that does not work. From a cursory look, your code seems correct. I just get a set of normal menu entries preceded with spaces, instead of submenus etc. regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: lyx-devel src/frontends/qt2/: ChangeLog Makefile.am Menubar_pi ...
On Wed, Aug 28, 2002 at 01:53:17PM +0200, Juergen Vigna wrote: Don't know. Maybe the same problem xforms had with menus which where too large? (too many entries). Possibly yes. It's not normal for Qt to have problems like this though, and the crash comes from LyX code regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: more on File menu for a single entry?
John == John Levon [EMAIL PROTECTED] writes: John On Wed, Aug 28, 2002 at 11:12:20AM +0200, Jean-Marc Lasgouttes John wrote: It is an idea of mine :) When moving the toc code out of the xforms frontend, I decided that the code that added 'More...' for long menus could better be used in the generic case. The menu length can be increased with constant max_number_of_items oor something like that. This is frontend-specific, as I guess qt has its own mechanism for dealing with long menus. John Ah right. What I can do is: 1/ avoid the stupid situation reported by hawk John How did it ever happen with File anyway ? Surely it only applies John to Navigate menu. Setting lastfile limit to an obscene value, maybe. JMarc
Re: Xforms: bug in fdesign or what?
On Wed, Aug 28, 2002 at 09:18:57PM +0900, Rob Lahaye wrote: I wonder if any LyX Xforms designer has ever bothered to get this right. Please speak up, if you have. Maybe it once worked with earlier versions of fdesign; but I truely believe fdesign that comes with 1.0.0 is broken for this purpose. Never even tried. It is rare that resizing works in xforms anyway. I'm talking about reducing the height, not the width. The text would still fit in, unless the german font is twice as large :) Anyway, I need first a properly working fdesign for this operation! Apparently the rule of thumb is 30%. Of course, for auto-sized stuff like Qt, it's a lot easier to get this right regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: more on File menu for a single entry?
On Wednesday 28 August 2002 16:58, Jean-Marc Lasgouttes wrote: Setting lastfile limit to an obscene value, maybe. The limit is 9, and I don't consider that an abscene since I use it. ;-) I changed the preferences value by hand but lyx detected that it was out of range [4,9] JMarc -- José Abílio
Re: lyx-devel lib/lyx2lyx/: lyxconvert_215.py
On Wed, Aug 28, 2002 at 04:54:08PM +0100, José Abílio Oliveira Matos wrote: Yes. I have done that until 0.10.7. For that version I have to install xforms 0.86. All others (including 1.2.1) can compile with 0.88. So my problem is 0.10.7, not all the others. :-) And even for 0.10.7 the code should be easy to compile the problems is xforms. Ditto for still older versions... Just comment out all the fl_message or whatever that it doesn't like, and do a little more fiddling, it DOES work. regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: more on File menu for a single entry?
On Wed, Aug 28, 2002 at 05:58:51PM +0200, Jean-Marc Lasgouttes wrote: John How did it ever happen with File anyway ? Surely it only applies John to Navigate menu. Setting lastfile limit to an obscene value, maybe. a) why do we have the ability to set a limit ? b) why do we have the ability to disable lastfiles ? regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: more on File menu for a single entry?
John Levon [EMAIL PROTECTED] writes: | On Wed, Aug 28, 2002 at 05:58:51PM +0200, Jean-Marc Lasgouttes wrote: John How did it ever happen with File anyway ? Surely it only applies John to Navigate menu. Setting lastfile limit to an obscene value, maybe. | a) why do we have the ability to set a limit ? why not? | b) why do we have the ability to disable lastfiles ? do we? -- Lgb
Re: undo's kill lyx
On Wed, Aug 28, 2002 at 05:41:31PM +0200, Jean-Marc Lasgouttes wrote: John == John Levon [EMAIL PROTECTED] writes: John At the very least we need a backtrace. A way to reproduce is John usually necessary for the undo stuff too :/ I think we have had several reports about undo (some of the recent bugs from MIchael). There is probably a bad undo bug somewhere. Check my original message again for good measure. I usually run lyx in a debugger anyway. I think I had one crash yesterday out of it (I had another running at the time), but there should be a back trace (unless it was a victim of my argeument with vim about autoindention within mutt . . .) hawk, who no longer has the message himself. -- Richard E. Hawkins, Asst. Prof. of Economics/\ ASCII ribbon campaign [EMAIL PROTECTED] Smeal 178 (814) 375-4700 \ / against HTML mail These opinions will not be those of Xand postings. Penn State until it pays my retainer. / \
Re: Xforms: bug in fdesign or what?
John Levon wrote: On Wed, Aug 28, 2002 at 09:18:57PM +0900, Rob Lahaye wrote: I wonder if any LyX Xforms designer has ever bothered to get this right. Please speak up, if you have. Never even tried. It is rare that resizing works in xforms anyway. With Jean-Marc's patch to fdesign, it actually does!! This is the proof: Resize your current xform Insert-Cross reference. Mess! Apply the attached patch and the mess is resolved. Xforms apparently can do proper resizing, if it's set up properly. Note that I have reduced the sizes of the widgets, to make this xforms dialog a little less bulky. Regards, Rob. crossRef.diff.gz Description: application/gzip
Re: more on File menu for a single entry?
On Wed, Aug 28, 2002 at 07:14:57PM +0200, Lars Gullik Bjønnes wrote: | a) why do we have the ability to set a limit ? why not? Are you serious ? Why don't we install an elephant recognising system into LyX too ? | b) why do we have the ability to disable lastfiles ? do we? It sure looks like it. Furthermore you can define the file used ! Bonkers ! john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: more on File menu for a single entry?
Setting lastfile limit to an obscene value, maybe. JAOM The limit is 9, and I don't consider that an abscene since I use it. ;-) JAOM I changed the preferences value by hand but lyx detected that it was out of JAOM range [4,9] Why not use a lastfiles value of X, and when there's X lastfiles display only X-2 in the menu and put the remaining 3+ lastfiles in the more list? Then it would at least look nicer... Philipp
Re: more on File menu for a single entry?
On Wed, Aug 28, 2002 at 07:49:44PM +0200, Philipp Reichmuth wrote: Why not use a lastfiles value of X, and when there's X lastfiles display only X-2 in the menu and put the remaining 3+ lastfiles in the more list? Then it would at least look nicer... Philipp Don't we do this already ? I think it was just a silly that JMarc added ... I see no reason to have this configurable (especially to such a silly range). regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Wed, Aug 28, 2002 at 04:38:48PM +0100, John Levon wrote: This does not necessarily mean less obvious bugs but rather less bugs, most of them easily fixable. Fiable for who ? e.g. the cannot click to the right of insets in 1.2.0cvs, probably easy for Jug etc. but took me hours to fix :/ For people like you and me. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Wed, Aug 28, 2002 at 07:55:28PM +0200, Andre Poenitz wrote:
Fiable for who ? e.g. the cannot click to the right of insets in
1.2.0cvs, probably easy for Jug etc. but took me hours to fix :/
For people like you and me.
What are the defining characteristics of this set ? it seems to be {x |
human(x) } ...
;)
regards
john
--
When your name is Winner, that's it. You don't need a nickname.
- Loser Lane
Re: more on File menu for a single entry?
On Wednesday 28 August 2002 18:55, John Levon wrote: Don't we do this already ? I think it was just a silly that JMarc added ... IIRC this code is from Lars. :-) Don't blame Jean-Marc, at least for this. ;-) I see no reason to have this configurable (especially to such a silly range). Actuallly the range should be [0..n], where 0 means no last file, the user doesn't need to choose the file where it is stored, after all we ca set different directories for different lyx versions... regards john -- José Abílio
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Wed, Aug 28, 2002 at 06:57:31PM +0100, John Levon wrote:
For people like you and me.
What are the defining characteristics of this set ? it seems to be {x |
human(x) } ...
{ x | has_seen_source_of_some_part_of_lyx(x) }
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: more on File menu for a single entry?
On Wed, Aug 28, 2002 at 07:10:51PM +0100, José Abílio Oliveira Matos wrote: IIRC this code is from Lars. :-) Don't blame Jean-Marc, at least for this. ;-) I was referring to More appearing in File menu Actuallly the range should be [0..n], where 0 means no last file, the user doesn't need to choose the file where it is stored, after all we ca set different directories for different lyx versions... I don't see a good reason to have this facility to disable lastfiles *at all*. Especially with my new menu layout regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Wed, Aug 28, 2002 at 08:05:19PM +0200, Andre Poenitz wrote:
{ x | has_seen_source_of_some_part_of_lyx(x) }
Well if you say so ! IME changes in this area inevitable lead to obscure
and confusing problems ...
regards
john
--
When your name is Winner, that's it. You don't need a nickname.
- Loser Lane
Re: more on File menu for a single entry?
JL I see no reason to have this configurable (especially to such a silly JL range). Of course, one could configure a maximum of 9, display up to 9 in the list and then break it at 7 to populate the submenu with 3 entries, but then the configurability loses a lot of its point. Maybe one could also make the break value configurable in addition to the maximum... :-) As far as I can see, it mainly makes sense to autobreak the list based to screen position, like widget systems do already. Philipp
Re: more on File menu for a single entry?
On Wed, Aug 28, 2002 at 08:11:41PM +0200, Philipp Reichmuth wrote: Of course, one could configure a maximum of 9, display up to 9 in the list and then break it at 7 to populate the submenu with 3 entries, but then the configurability loses a lot of its point. Maybe one could also make the break value configurable in addition to the maximum... :-) As far as I can see, it mainly makes sense to autobreak the list based to screen position, like widget systems do already. I think the best solution is to hardcode (9 ?) it, and move it to a submenu like most other programs do. That way there is no intrusion upon the main menu (*especially* for finding File-exit). regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Wed, Aug 28, 2002 at 07:09:18PM +0100, John Levon wrote:
On Wed, Aug 28, 2002 at 08:05:19PM +0200, Andre Poenitz wrote:
{ x | has_seen_source_of_some_part_of_lyx(x) }
Well if you say so ! IME changes in this area inevitable lead to obscure
and confusing problems ...
That's why I think it needs to be cleaned up first. If that's done bugs are
easy to fix
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS Bug: LeftMouseClick does not open graphics dialog in float.
On Wed, Aug 28, 2002 at 08:20:16PM +0200, Andre Poenitz wrote: Well if you say so ! IME changes in this area inevitable lead to obscure and confusing problems ... That's why I think it needs to be cleaned up first. If that's done bugs are easy to fix /me boggles Isn't that what I said originally ?? Yes, one day, changes to lyx will be more likely to only cause obvious errors, because we will have good extendable code in place. But Right Now it's crufty as hell, and every change will likely cause some subtle non-obvious bugs. This is why I'm saying these changes are going to delay 1.3 even more (after the bugs caused by GUII have already caused a certain amount) regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
Re: more on File menu for a single entry?
John Levon [EMAIL PROTECTED] writes: | On Wed, Aug 28, 2002 at 07:14:57PM +0200, Lars Gullik Bjønnes wrote: | | | a) why do we have the ability to set a limit ? | | why not? | | Are you serious ? | | Why don't we install an elephant recognising system into LyX too ? That would only be a benefit for elephant hunters, and we do not have many of those as users. | | b) why do we have the ability to disable lastfiles ? | | do we? | | It sure looks like it. Furthermore you can define the file used ! | Bonkers ! It seemed logical at the time. -- Lgb
Re: more on File menu for a single entry?
On Wed, Aug 28, 2002 at 08:48:27PM +0200, Lars Gullik Bjønnes wrote: | why not? | | Are you serious ? | | Why don't we install an elephant recognising system into LyX too ? That would only be a benefit for elephant hunters, and we do not have many of those as users. We also don't have many people (any ?) who seriously need to be able to configure lastfiles between 4 and 9 !! It's yet more prefs clutter - can I please remove it ? regards john -- When your name is Winner, that's it. You don't need a nickname. - Loser Lane
