Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wed, 15 Nov 2006, Abdelrazak Younes wrote: perhaps 'M-s', to this action (combined with a separate GUI button)? We already have Alt-M-s and that's fine. But I would like something even simpler than that. What the heck does 'Alt-M-s' mean? Or do you mean 'M-p s'? (I thought Alt and Meta was the same key...) Yep typo, sorry, I really meant Alt+p s No worries, I just got confused :-) Actually it'd be quite funny to see a new (Windows) user try and find the combination 'Alt-M-s'... In another post, Jean-Marc wrote: Georg I have added a button to my toolbar to do this. It is not 100% Georg fool proof (because it uses layout Standard, and the default Georg layout is named differently in some classes), but for me it is Georg OK. We could decide that layout-paragraph without argument sets layout to default. Jean-Marc, do you really mean 'layout-paragraph'? Fiddling a bit I thought it was 'layout' that changes the layout. Using 'layout-paragraph' brings up a dialog. I'll assume it is 'layout' in what I write below. I'll try to summarize the different alternatives discussed in this thread: Currently available alternatives: * Use keyboard shortcut 'M-p s' * Use 'M-x layout Standard', i.e * Use the pull-down list with environments and select Standard I *think* that an (expert) user can currently also configure his system a bit so the followin alternatives also become available: * Bind a command-sequence to e.g. M-C-s that invokes 'layout Standard' using: \bind M-C-s command-sequence layout Standard; * Create a toolbar button for this purpose by creating and icon with the name (?) command-sequence layout Standard; and place it in the directory ??. LyX will then execute the command when the user clicks on the icon. (Is this how you do it, I don't remember!) Any of the expert alternatives above could of course be made to work in a new release of a LyX by default. New suggestions and alternatives: * new-1 (Andreas): Click Decrease depth buton and if on the first level, (and in Itemize/Enumerate/Descirption/List), the environment changes to Standard. ** Make it work only for Itemize/Enumerate that is not followed by any text, i.e. for * empty but not for * text... * new-2 (Abdel): If the paragraph is empty, BackSpace switches to Standard instead of deleting the paragraph. (In order to delete a paragraph you have to press BackSpace twice). * new-3 (JMarc): Make 'layout' without argument set the paragraph to Standard (or whatever the standard paragraph type is called). This makes it easier to get a button to work in all types of document. * new-4 (JMarc): kill break-paragraph-keep-layout (M-Return) and recycle the binding to a new break-paragraph-reset-layout that would: - insert a paragraph break - reduce depth by one - set the layout to the one of the enclosing nesting (think enumerate in itemize) or the standard layout at depth 0. I think the resetting at the time of a paragraph break is better than after the fact. (Note: I didn't get this bit...) * new-5 (Abdel): Extend the dEPM mechanism: Typing return twice after a list or an enumeration automatically switches the paragraph layout to Standard. I think that we should do the following: * Do 'new-3', i.e. let 'layout' without argument set the paragraph layout to Standard * Create an (optional?) toolbar button for changing to Standard If we in addition should do something, I think that 'new-5' sounds interesting, i.e. return twice after a list changes to Standard. cheers /Christian PS. I discovered that the argument of the LFUN layout is case sensitive. In other words, 'layout Standard' works but 'layout standard' doesn't. Maybe it should be case insensitive? -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: setting tabular lines in multicolumn cells
Edwin Leuven wrote: Michael Gerz wrote: Edwin Leuven wrote: is there a reason to have both M_TOGGLE_LINE_TOP and TOGGLE_LINE_TOP ? couldn't we just have one TOGGLE_LINE_TOP and set the proper flags depending whether we are in a multicolumn cell or not? This is exactly what I proposed for 1.4 :-) the attach patch does just that... Georg Baum wrote: what happened? Nobody dared to open the can of worms that the tabular inset is. IMO the tabular code that is spread over tabular.C and insets/insettabular.C needs to be put into one file and almost completely rewritten. Of course now is not the time to do so... agreed. the patch is an improvement to the current code though because it basically gets rid of the M_TOGGLE_LINE stuff... I had a closer look, and IMHO it is only partly an improvement. You remove the functionality to set the borders of whole columns/rows. This is useful functionality that should not be removed. For example I could have a table with several columns, including multicolumn cells, where some have top lines and decide that I rather do not want any top row. I therefore want to be able to set or reset the top lines of a whole row. For toggling I agree: It does only make sense to toggle what is currently used, e.g. if at least one cell of a row has an individual top/bottom line setting that setting should be toggled. If the whole row has the same setting then the whole row should be toggled. The same applies of course to left/right lines and columns. moreover, atm the dialog and toolbar give inconsistent results. the patch solves that (and gets rid of a bog). Which one? I just committed apatch that renames the arguments of the tabular methods that you want to remove. These are useful IMO, even if they are currently not used by the dialog, so they should be kept. Maybe you now see what these arguments mean after I gave them meaningful names. If you rework your patch to not remove this functionality then it would be OK with me. It would be even better if it would be possible to set/reset whole column/row lines in the dialog, but since the dialog is horribly broken anwyway this can also wait. the only thing left is the enabling/disabling of the toolbuttons (which btw is not done atm either) it is not really clear to me in what situations we should allow what. i found the following comment: // pay attention to left/right lines: they are only allowed // to set if we are in first/last cell of row or if the left/right // cell is also a multicolumn. why is that, and what would be the preferred policy here? This is the multicolumn case (normal cells are handled above that comment). It is not possible to set left/right lines inside of a multicolumn cell, they can of course only be set at the leftmost/rightmost cell of a multicolumn cell. This is one area where the code could be simplified (e.g. do not use dummy cells for multicolumn cells, but just one cell), but I believe that the current code is correct here. what would be a good way of setting lines anyway? (am not a latex expert) on a per cell basis using \cline and switching to \hline when all columns are spanned? This is done AFAIK. not in the user interface What do you mean? You can set the lines in the UI per cell. If all lines in a row are set this results in a \hline, otherwise in one or more \cline. What else has \cline and \hline to do with the user interface? Georg
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
[EMAIL PROTECTED] wrote:
* Create a toolbar button for this purpose by creating and icon with
the name (?)
It would need to be called layout_Standard.xpm.
command-sequence layout Standard;
and place it in the directory ??. LyX will then execute the
command when the user clicks on the icon.
(Is this how you do it, I don't remember!)
No, only layout Standard.
* Do 'new-3', i.e. let 'layout' without argument set the paragraph layout
to Standard
* Create an (optional?) toolbar button for changing to Standard
Wrong!!!
Not Standard, but the default layout of the text class. Not all classes
have a Standard layout, but all have a default layout.
The attached patch implements this. OK to go in? Before or after alpha? BTW
there was a layout.xpm icon in 1.3. What was its purpose? Should we use
it instead of my new one?
PS. I discovered that the argument of the LFUN layout is case sensitive.
In other words, 'layout Standard' works but 'layout standard' doesn't.
Maybe it should be case insensitive?
Why? Are layout names case insensitive elsewhere?
GeorgIndex: src/text3.C
===
--- src/text3.C (Revision 15932)
+++ src/text3.C (Arbeitskopie)
@@ -809,24 +809,15 @@ void LyXText::dispatch(LCursor cur, Fu
break;
case LFUN_LAYOUT: {
- lyxerr[Debug::INFO] LFUN_LAYOUT: (arg)
- to_utf8(cmd.argument()) endl;
-
- // This is not the good solution to the empty argument
- // problem, but it will hopefully suffice for 1.2.0.
- // The correct solution would be to augument the
- // function list/array with information about what
- // functions needs arguments and their type.
- if (cmd.argument().empty()) {
- cur.errorMessage(_(LyX function 'layout' needs an argument.));
- break;
- }
+ string layout = to_ascii(cmd.argument());
+ lyxerr[Debug::INFO] LFUN_LAYOUT: (arg) layout endl;
// Derive layout number from given argument (string)
// and current buffer's textclass (number)
LyXTextClass const tclass = bv-buffer()-params().getLyXTextClass();
- bool hasLayout = tclass.hasLayout(to_utf8(cmd.argument()));
- string layout = to_utf8(cmd.argument());
+ if (layout.empty())
+ layout = tclass.defaultLayoutName();
+ bool hasLayout = tclass.hasLayout(layout);
// If the entry is obsolete, use the new one instead.
if (hasLayout) {
Index: lib/images/layout.xpm
===
--- lib/images/layout.xpm (Revision 0)
+++ lib/images/layout.xpm (Revision 0)
@@ -0,0 +1,25 @@
+/* XPM */
+static char * layout_xpm[] = {
+20 20 2 1,
+ c None,
+. c #00,
+,
+,
+ . ,
+,
+,
+ . ,
+,
+,
+ . ,
+,
+,
+ . ,
+,
+,
+ . ,
+,
+,
+ . ,
+,
+};
Index: lib/ui/stdtoolbars.ui
===
--- lib/ui/stdtoolbars.ui (Revision 15932)
+++ lib/ui/stdtoolbars.ui (Arbeitskopie)
@@ -63,6 +63,7 @@ Toolbar standard Standard
End
Toolbar extra Extra
+ Item Default layout
Item Numbered list layout Enumerate
Item Itemized list layout Itemize
Item List layout List
lyx143: export to HTML and MS WORD (HTML)
Hi, if you do the above it looks like MS WORD (HTML) converts special characters to unicode (for example ä - #x00E4;), but the normal export to HTML does not. Which parameter of htlatex $$i 'html,word' 'symbol/!' '-cvalidate' is responsible for the conversion to unicode? And should not do the normal export to HTML this by default, too? Additionally: if export to html, delete the html-file and export again, LyX asks you if you want to overwrite the html-file, although it has already stored the new file. -- Viele Grüße, Hartmut Hungerhilfe: http://www.thehungersite.com Kampagne gegen den Ausverkauf der Deutschen Bahn: http://www.bahn-fuer-alle.de Das heutige Motto: Vergoldete Bücher machen aus faulen Studenten keine Doktoren.
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg The attached patch implements this. OK to go in? I like it. PS. I discovered that the argument of the LFUN layout is case sensitive. In other words, 'layout Standard' works but 'layout standard' doesn't. Maybe it should be case insensitive? Georg Why? Are layout names case insensitive elsewhere? No, I do not think so. JMarc
Re: setting tabular lines in multicolumn cells
Georg Baum wrote: I had a closer look, and IMHO it is only partly an improvement. You remove the functionality to set the borders of whole columns/rows. i think that it is possible to set borders of whole cols/rows. just select them and set/unset them. This is useful functionality that should not be removed. For example I could have a table with several columns, including multicolumn cells, where some have top lines and decide that I rather do not want any top row. I therefore want to be able to set or reset the top lines of a whole row. For toggling I agree: It does only make sense to toggle what is currently used, e.g. if at least one cell of a row has an individual top/bottom line setting that setting should be toggled. If the whole row has the same setting then the whole row should be toggled. The same applies of course to left/right lines and columns. afaics my changes make the dialog and toolbar act in a consistent way which i think is what people expect. If you rework your patch to not remove this functionality then it would be OK with me. It would be even better if it would be possible to set/reset whole column/row lines in the dialog, but since the dialog is horribly broken anwyway this can also wait. can you give me an example what you are missing? i didn't follow the one above. (i might be wrong but there is no table you cannot make after the patch that you could make before.) the only thing that is different with my patch is that when the cursor is in a multicolumn cell toggling applies to that cell's borders. it is not possible to toggle left/right (unless it is at the border of the table or if there is an adjacent multicolumn cell). to toggle left/right for the column either move to a non multicolumn cell or select the column. note that it behaves like the dialog. the unpatched toolbar otoh toggles the whole left/right colomn line setting (except the multi col ones) when in a multicol cell. more in general i think that it makes sense to have the toggling apply to what is selected: cursor in cell - toggle cell selection - toggle selection want to change the whole row/col? - select row/col and toggle it is not really clear to me in what situations we should allow what. i found the following comment: // pay attention to left/right lines: they are only allowed // to set if we are in first/last cell of row or if the left/right // cell is also a multicolumn. why is that, and what would be the preferred policy here? This is the multicolumn case (normal cells are handled above that comment). It is not possible to set left/right lines inside of a multicolumn cell, they can of course only be set at the leftmost/rightmost cell of a multicolumn cell. the strange thing is that this comment is in the frontend whereas what you are saying should be handled by the core... What do you mean? You can set the lines in the UI per cell. If all lines in a row are set this results in a \hline, otherwise in one or more \cline. What else has \cline and \hline to do with the user interface? how do you do that? i don't manage to have a horizontal line that spans only a few columns unless i make the cell multicolumns cells... thanks, ed.
Re: Crash in view-something with Extended-Insets.lyx
On Tuesday 14 November 2006 8:46 pm, Georg Baum wrote: It was a lyx2lyx problem as I suspected, and I fixed it. José, if you have a more elegant solution feel free to use that, but I wanted to make sure that this is fixed as soon as possible. Sure, I was really amused when I saw your change. :-) nestdepth = nestdepth + 1 The right idiom is nestdepth += 1 and the same when you the nesting depth nestdepth -= 1 Georg -- José Abílio
Re: Crash in view-something with Extended-Insets.lyx
Am Dienstag, 14. November 2006 21:46 schrieb Georg Baum: It was a lyx2lyx problem as I suspected, and I fixed it. José, if you have a more elegant solution feel free to use that, but I wanted to make sure that this is fixed as soon as possible. Converted Extended-Insets.lyx looks now ok, but it still crashes here e.g. on export-latex Kornel -- Kornel Benko [EMAIL PROTECTED] pgpkwXhNMHA89.pgp Description: PGP signature
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
On Tuesday 14 November 2006 8:26 am, Georg Baum wrote: José Matos wrote: Should we place this in bugzilla so that it does not get forgotten? Feel free to to so. Done, http://bugzilla.lyx.org/show_bug.cgi?id=2992 Georg -- José Abílio
Re: CT Status Quo
On Sunday 12 November 2006 11:10 pm, Michael Gerz wrote: Dear Jose, Nov 13th is getting closer (oops, it's already there) and, to my greatest regret, I haven't managed to fix all CT problems. That is OK. :-) AFAICS, the following things do not work presently: - No change bar is given in LaTeX output if (only) the par break has changed - No visual clue is presente to the user, which indicates the status of the imaginary end-of-par character. - In tables, cut paste (complete cells) do not support change tracking - Capitalize, Uppercase, and Lowercase are broken and must be rewritten to better support CT - When accepting or rejecting changes, paragraphs with deleted par breaks are not merged in nested text insets - There may be potential problems with breaking paragraphs (two places in the code look suspicious) - When accepting a change, LyX may hang (same as in 1.4.3) Maybe this should be add to the file created by Christian as missing features, no? Jose, I don't know whether you are going to publish LyX 1.5alpha today. IMHO, none of the open issues above should stop you from doing so. I am pretty confident that CT is already in a better state than it is in 1.4.3. People, who don't use CT, shouldn't be affected at all. Moreover, there is bigger problems (e.g., broken spell checker). Nevertheless, the open issues MUST be addressed for the first LyX 1.5beta. Sure. Unfortunately, I won't be able to work on the open issues in the next two days. With a little luck, I will continue on Wednesday. No problem, we all have a life outside LyX. (Do we?) ;-) Regards, Michael PS: I like the way LyX 1.5 evolves. The LyX developers have become a real good team! I agree. :-) -- José Abílio
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wed, 15 Nov 2006, Georg Baum wrote: PS. I discovered that the argument of the LFUN layout is case sensitive. In other words, 'layout Standard' works but 'layout standard' doesn't. Maybe it should be case insensitive? Why? Are layout names case insensitive elsewhere? No, but maybe case insensitivity would make it easier to change between document layouts? I'm thinking of cases where the two document layouts use Standard v.s. standard for the same paragraph layout. /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [PATCH] Optimize drawing (was Re: CT Status Quo)
On Sunday 12 November 2006 11:38 pm, Abdelrazak Younes wrote: I might not be ready for this alpha but I will for the next. Thanks Abdel. I would like to have feedback from Bennet before putting this in. I think that we are in the right track. :-) Abdel. -- José Abílio
Re: [Patch] outline + undo (Re: TOC-crach backtrace)
On Monday 13 November 2006 2:11 pm, Jean-Marc Lasgouttes wrote: The bug is: do some random up/down in outline, mixed with some undo. Either the text becomes a mess, or one gets a crash. What do you think of this patch Jean-Marc? JMarc -- José Abílio
Re: [Patch] outline + undo (Re: TOC-crach backtrace)
José == José Matos [EMAIL PROTECTED] writes: José On Monday 13 November 2006 2:11 pm, Jean-Marc Lasgouttes wrote: The bug is: do some random up/down in outline, mixed with some undo. Either the text becomes a mess, or one gets a crash. José What do you think of this patch Jean-Marc? I think that I have not tested it either, but I did test the 1.4 version and see no reason why it should not work. So accepting it is an act of faith :) JMarc
Re: [PATCH] Optimize drawing
On Tuesday 14 November 2006 5:18 pm, Abdelrazak Younes wrote: Hello, Between two chunk of work, I've managed to finish the patch, so here it is. Good. With this patch, when you click anywhere, including within nested text insets (not for mathed), there is no redrawing at _all_. This is an improvement over lyx-1.4 where the full screen were redrawn two times on each mouse click. I think this is a necessary improvement for Mac so, Jose, do you want it for this alpha or shall I wait until it is released? I think I have tested it enough already but I will understand if you'd like to wait. On the other hand, this is the typical feature that needs a lot of testing so the sooner users can test it, the better... you decide. I would like to hear a first feedback from Bennett as I said in the other message regarding your first patch. Without this I am chancing a shot in the dark. The next target for optimisation is mathed. Right now, any mouse click or character typed inside a math inset will result in a full screen redraw (this is the case also for 1.4). For Mac, this is prohibitive. OK. Then, I will try to investigate if we could use a pixmap cache. But this last work will probably be for 1.6. I agree. Abdel. -- José Abílio
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
christian == christian ridderstrom [EMAIL PROTECTED] writes: christian No, but maybe case insensitivity would make it easier to christian change between document layouts? I'm thinking of cases christian where the two document layouts use Standard v.s. christian standard for the same paragraph layout. No, we try to stay away from case insensitivity as much as possible. What we could do though, is to name the style standard and give it a GUI name of Standard. But this is too much work for a small gain. JMarc
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wednesday 15 November 2006 9:52 am, Georg Baum wrote: The attached patch implements this. OK to go in? Yes. Before or after alpha? After, please. -- José Abílio
Re: [PATCH] Optimize drawing
José == José Matos [EMAIL PROTECTED] writes: With this patch, when you click anywhere, including within nested text insets (not for mathed), there is no redrawing at _all_. This is an improvement over lyx-1.4 where the full screen were redrawn two times on each mouse click. I think this is a necessary improvement for Mac so, Jose, do you want it for this alpha or shall I wait until it is released? I think I have tested it enough already but I will understand if you'd like to wait. On the other hand, this is the typical feature that needs a lot of testing so the sooner users can test it, the better... you decide. José I would like to hear a first feedback from Bennett as I said José in the other message regarding your first patch. José Without this I am chancing a shot in the dark. While the patch looks like a necessary cleanup, I am not sure it makes a big difference for the cases that are plaguing the mac (says the man who did not test the patch). Abdel, besides the do it right aspect of the patch, do you feel it has a big real-life impact? One such impact could be in speed in selection with mouse, for example. JMarc
Re: [Patch] outline + undo (Re: TOC-crach backtrace)
On Wednesday 15 November 2006 12:11 pm, Jean-Marc Lasgouttes wrote: I think that I have not tested it either, but I did test the 1.4 version and see no reason why it should not work. Fair enough. :-) So accepting it is an act of faith :) I am a man of faith, but not that much. ;-) The patch, with some testing, can go after the first alpha. :-) JMarc -- José Abílio
Re: [Patch] outline + undo (Re: TOC-crach backtrace)
José == José Matos [EMAIL PROTECTED] writes: José On Wednesday 15 November 2006 12:11 pm, Jean-Marc Lasgouttes José wrote: I think that I have not tested it either, but I did test the 1.4 version and see no reason why it should not work. José Fair enough. :-) So accepting it is an act of faith :) José I am a man of faith, but not that much. ;-) I underestimated you, then ;) JMarc
Re: [PATCH] Optimize drawing
Jean-Marc Lasgouttes wrote: José == José Matos [EMAIL PROTECTED] writes: With this patch, when you click anywhere, including within nested text insets (not for mathed), there is no redrawing at _all_. This is an improvement over lyx-1.4 where the full screen were redrawn two times on each mouse click. I think this is a necessary improvement for Mac so, Jose, do you want it for this alpha or shall I wait until it is released? I think I have tested it enough already but I will understand if you'd like to wait. On the other hand, this is the typical feature that needs a lot of testing so the sooner users can test it, the better... you decide. José I would like to hear a first feedback from Bennett as I said José in the other message regarding your first patch. José Without this I am chancing a shot in the dark. While the patch looks like a necessary cleanup, I am not sure it makes a big difference for the cases that are plaguing the mac (says the man who did not test the patch). Well, it does impact what the Mac user would feel. Waiting a second or two on each mouse click is not funny I guess. Abdel, besides the do it right aspect of the patch, do you feel it has a big real-life impact? One such impact could be in speed in selection with mouse, for example. Not yet, no, not on selection unfortunately, but I plan to work on this also afterward. And as you said, this patch is a necessary cleanup for further optimisation. Abdel.
Re: [PATCH] Optimize drawing
José Matos wrote: On Tuesday 14 November 2006 5:18 pm, Abdelrazak Younes wrote: With this patch, when you click anywhere, including within nested text insets (not for mathed), there is no redrawing at _all_. This is an improvement over lyx-1.4 where the full screen were redrawn two times on each mouse click. I think this is a necessary improvement for Mac so, Jose, do you want it for this alpha or shall I wait until it is released? I think I have tested it enough already but I will understand if you'd like to wait. On the other hand, this is the typical feature that needs a lot of testing so the sooner users can test it, the better... you decide. I would like to hear a first feedback from Bennett as I said in the other message regarding your first patch. Without this I am chancing a shot in the dark. Sure. Let's wait for Bennett, then. Or maybe Andreas... are you reading this Andreas? Abdel.
Re: setting tabular lines in multicolumn cells
Edwin Leuven wrote:
Georg Baum wrote:
I had a closer look, and IMHO it is only partly an improvement. You
remove the functionality to set the borders of whole columns/rows.
i think that it is possible to set borders of whole cols/rows. just
select them and set/unset them.
And how is that implemented? I do not understand how you can remove the
wholerow/wholecolumn arguments of some LyXTabular methods without making
this impossible.
afaics my changes make the dialog and toolbar act in a consistent way
which i think is what people expect.
Yes, and I agree with that.
If you rework your patch to not remove this functionality then it
would be OK with me. It would be even better if it would be possible
to set/reset whole column/row lines in the dialog, but since the
dialog is horribly broken anwyway this can also wait.
can you give me an example what you are missing? i didn't follow the one
above. (i might be wrong but there is no table you cannot make after the
patch that you could make before.)
I did not try the patch, but from looking at it I saw that you removed the
last argument of the topLine() etc. methods. That means that existing
functionality is removed. Do you know what that means in
InsetTabular::copySelection()?
the only thing that is different with my patch is that when the cursor
is in a multicolumn cell toggling applies to that cell's borders.
No, you also changed copying.
more in general i think that it makes sense to have the toggling apply
to what is selected:
cursor in cell - toggle cell
selection - toggle selection
want to change the whole row/col? - select row/col and toggle
That makes sense. As I wrote, I am in favour of the toggling part of your
patch. What I do not like is that you remove the boolean flags of the
LyXTabular methods. I do not understand why these are not used for setting
the lines of whole rows/columns. That probably means some duplicate code. I
really would like to preserve these arguments and reuse these methods later
for changing whole columns/rows.
the strange thing is that this comment is in the frontend whereas what
you are saying should be handled by the core...
As I wrote: can of worms.
What do you mean? You can set the lines in the UI per cell. If all
lines in a row are set this results in a \hline, otherwise in one or
more \cline. What else has \cline and \hline to do with the user
interface?
how do you do that? i don't manage to have a horizontal line that spans
only a few columns unless i make the cell multicolumns cells...
Correct. I think now I understand what you mean: It is not possible to
change the top/bottom line of just one cell if it is not a multicolumn
cell. That is a strange limitation that should be removed. Again: Can of
worms.
BTW, you forgot to remove some enum values. Here is an updated version of
your patch.
GeorgIndex: src/insets/insettabular.C
===
--- src/insets/insettabular.C (Revision 15932)
+++ src/insets/insettabular.C (Arbeitskopie)
@@ -108,10 +108,6 @@ TabularFeature tabularFeature[] =
{ LyXTabular::VALIGN_TOP, valign-top },
{ LyXTabular::VALIGN_BOTTOM, valign-bottom },
{ LyXTabular::VALIGN_MIDDLE, valign-middle },
- { LyXTabular::M_TOGGLE_LINE_TOP, m-toggle-line-top },
- { LyXTabular::M_TOGGLE_LINE_BOTTOM, m-toggle-line-bottom },
- { LyXTabular::M_TOGGLE_LINE_LEFT, m-toggle-line-left },
- { LyXTabular::M_TOGGLE_LINE_RIGHT, m-toggle-line-right },
{ LyXTabular::M_ALIGN_LEFT, m-align-left },
{ LyXTabular::M_ALIGN_RIGHT, m-align-right },
{ LyXTabular::M_ALIGN_CENTER, m-align-center },
@@ -843,28 +839,20 @@ bool InsetTabular::getStatus(LCursor c
status.setOnOff(tabular.isMultiColumn(cur.idx()));
break;
- case LyXTabular::M_TOGGLE_LINE_TOP:
- flag = false;
case LyXTabular::TOGGLE_LINE_TOP:
- status.setOnOff(tabular.topLine(cur.idx(), flag));
+ status.setOnOff(tabular.topLine(cur.idx()));
break;
- case LyXTabular::M_TOGGLE_LINE_BOTTOM:
- flag = false;
case LyXTabular::TOGGLE_LINE_BOTTOM:
- status.setOnOff(tabular.bottomLine(cur.idx(), flag));
+ status.setOnOff(tabular.bottomLine(cur.idx()));
break;
- case LyXTabular::M_TOGGLE_LINE_LEFT:
- flag = false;
case LyXTabular::TOGGLE_LINE_LEFT:
- status.setOnOff(tabular.leftLine(cur.idx(), flag));
+ status.setOnOff(tabular.leftLine(cur.idx()));
break;
- case LyXTabular::M_TOGGLE_LINE_RIGHT:
- flag = false;
case LyXTabular::TOGGLE_LINE_RIGHT:
- status.setOnOff(tabular.rightLine(cur.idx(), flag));
+ status.setOnOff(tabular.rightLine(cur.idx()));
break;
case LyXTabular::M_ALIGN_LEFT:
@@ -1477,54 +1465,35 @@ void InsetTabular::tabularFeatures(LCurs
cur.idx() = tabular.getCellNumber(row, column);
break;
- case LyXTabular::M_TOGGLE_LINE_TOP:
- flag = false;
case LyXTabular::TOGGLE_LINE_TOP: {
- bool lineSet = !tabular.topLine(cur.idx(), flag);
+ bool lineSet =
Re: Crash in view-something with Extended-Insets.lyx
On Wednesday 15 November 2006 11:46 am, Kornel Benko wrote: Converted Extended-Insets.lyx looks now ok, but it still crashes here e.g. on export-latex For me it does not crash, it does not produce any output though because I don't have prettyref installed. Kornel -- José Abílio
Re: Crash in view-something with Extended-Insets.lyx
Kornel Benko wrote: Am Dienstag, 14. November 2006 21:46 schrieb Georg Baum: Converted Extended-Insets.lyx looks now ok, but it still crashes here e.g. on export-latex For me it works. I guess you are on linux. Which version of gcc/libc? Can you compile with debug info so that we can get line numbers in the backtrace? Georg
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
[EMAIL PROTECTED] wrote: On Wed, 15 Nov 2006, Georg Baum wrote: PS. I discovered that the argument of the LFUN layout is case sensitive. In other words, 'layout Standard' works but 'layout standard' doesn't. Maybe it should be case insensitive? Why? Are layout names case insensitive elsewhere? No, but maybe case insensitivity would make it easier to change between document layouts? I'm thinking of cases where the two document layouts use Standard v.s. standard for the same paragraph layout. We have the obsoletedby keyword for such cases. Apart from that this should not happen: People who write layout files should reuse existing names. Georg
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
Jean-Marc Lasgouttes wrote: No, we try to stay away from case insensitivity as much as possible. Good. That I wanted to hear :-) I hate case insensitivity. Normally it makes life more complicated than easier, because you remove case as an additional possibility to distinguish something. Georg
Re: [Patch] outline + undo (Re: TOC-crach backtrace)
José Matos wrote: On Wednesday 15 November 2006 12:11 pm, Jean-Marc Lasgouttes wrote: I think that I have not tested it either, but I did test the 1.4 version and see no reason why it should not work. Fair enough. :-) So accepting it is an act of faith :) I am a man of faith, but not that much. ;-) The patch, with some testing, can go after the first alpha. :-) I just tested it briefly, it seems to do no harm. But I didn't see the crashes without the patch at the first place. I think it is reasonably safer to apply it just after the first alpha. Abdel.
Re: [PATCH] Optimize drawing
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Well, it does impact what the Mac user would feel. Waiting Abdelrazak a second or two on each mouse click is not funny I guess. A second or two? I missed that. Abdel, besides the do it right aspect of the patch, do you feel it has a big real-life impact? One such impact could be in speed in selection with mouse, for example. Abdelrazak Not yet, no, not on selection unfortunately, but I plan to Abdelrazak work on this also afterward. And as you said, this patch Abdelrazak is a necessary cleanup for further optimisation. I think that, if it is a big gain, it should go in 1.5.0, but ongoing cleanup is less urgent. OTOH, if you continue working on that without committing, the patch would become too large to be evaluated. JMarc
SHOWSTOPPER: class Book missing with current SVN, is that normal?
Jose, Before releasing a first alpha, I think the following should be solved: Trying to open Extended.lyx, LyX tells me that the Book document class is missing so it tries to use the article class; which is not good for obvious reason. This is on Windows-XP with a CMake build. By the way, shouldn't the documentation be converted to utf8? Or is that already done? Abdel.
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: christian == christian ridderstrom [EMAIL PROTECTED] writes: christian No, but maybe case insensitivity would make it easier to christian change between document layouts? I'm thinking of cases christian where the two document layouts use Standard v.s. christian standard for the same paragraph layout. Jean-Marc No, we try to stay away from case insensitivity as much as Jean-Marc possible. What we could do though, is to name the style Jean-Marc standard and give it a GUI name of Standard. But this Jean-Marc is too much work for a small gain. I saw after sending this that José just entered the corresponding bug! JMarc
Re: SHOWSTOPPER: class Book missing with current SVN, is that normal?
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak By the way, shouldn't the documentation be converted to Abdelrazak utf8? Or is that already done? I think we can wait a bit for that. A bonus is that it allows us to test lyx2lyx :) JMarc
Re: [PATCH] Optimize drawing
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak Well, it does impact what the Mac user would feel. Waiting Abdelrazak a second or two on each mouse click is not funny I guess. A second or two? I missed that. I seem to remember that from Bennett yes. Considering that each click results in two full screen paintings and that Qt4 on Mac is so sloowww, this is no surprise. Abdel, besides the do it right aspect of the patch, do you feel it has a big real-life impact? One such impact could be in speed in selection with mouse, for example. Abdelrazak Not yet, no, not on selection unfortunately, but I plan to Abdelrazak work on this also afterward. And as you said, this patch Abdelrazak is a necessary cleanup for further optimisation. I think that, if it is a big gain, I think it will. it should go in 1.5.0, but ongoing cleanup is less urgent. OTOH, if you continue working on that without committing, the patch would become too large to be evaluated. IMO, optimizing LyX is a must for 1.5.0. Current drawing strategy is really, *really*, complicated. So cleanups are necessary in order to optimize it. Abdel.
Re: [PATCH] Optimize drawing
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak IMO, optimizing LyX is a must for 1.5.0. Current drawing Abdelrazak strategy is really, *really*, complicated. So cleanups are Abdelrazak necessary in order to optimize it. I agree that we shall take the time to speed up 1.5. But you should make sure first that Jose will give you the time to do it well... JMarc
showstopper: cursor positioning with tables
1. new doc 2. insert a table 3. add some columns then try to put the cursor in one of the appended columns: this is not possible also not possible to put the cursor after the table
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 13:44 schrieb Georg Baum: Kornel Benko wrote: Am Dienstag, 14. November 2006 21:46 schrieb Georg Baum: Converted Extended-Insets.lyx looks now ok, but it still crashes here e.g. on export-latex For me it works. I guess you are on linux. Which version of gcc/libc? #gcc --version gcc (GCC) 3.3.4 (pre 3.3.5 20040809) ... Can you compile with debug info so that we can get line numbers in the backtrace? Sure. I try. But it takes a while. Kornel -- Kornel Benko [EMAIL PROTECTED] pgpHWdc99toSM.pgp Description: PGP signature
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wed, 15 Nov 2006, Georg Baum wrote: On Wed, 15 Nov 2006, Georg Baum wrote: PS. I discovered that the argument of the LFUN layout is case sensitive. In other words, 'layout Standard' works but 'layout standard' doesn't. Maybe it should be case insensitive? Why? Are layout names case insensitive elsewhere? No, but maybe case insensitivity would make it easier to change between document layouts? I'm thinking of cases where the two document layouts use Standard v.s. standard for the same paragraph layout. We have the obsoletedby keyword for such cases. Apart from that this should not happen: People who write layout files should reuse existing names. Great! I was about to ask for something like that. Just to be on the safe side and avoid confusion: The original problem is this: * You set a paragraph layout to something, e.g. Section * You change document class to something else that happens to not have the layout Section. Oops, that section now became default. * You decide it was too much trouble and changes the document class back to the original class. Damn, that section is still default. Will the problem I just described be fixed with the help of obsoletedby? (And is it stored in the .lyx-file, so it doesn't matter if you saved the file in between). /Christian PS. I also hate case insensitivity by the way... felt really strange arguing for it. -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wednesday 15 November 2006 1:40 pm, [EMAIL PROTECTED] wrote: Great! I was about to ask for something like that. Just to be on the safe side and avoid confusion: The original problem is this: * You set a paragraph layout to something, e.g. Section * You change document class to something else that happens to not have the layout Section. Oops, that section now became default. * You decide it was too much trouble and changes the document class back to the original class. Damn, that section is still default. Will the problem I just described be fixed with the help of obsoletedby? (And is it stored in the .lyx-file, so it doesn't matter if you saved the file in between). I don't think so. What are describing would involve for each paragraph to remember part of its history. We have never been able to recover from such case. /Christian PS. I also hate case insensitivity by the way... felt really strange arguing for it. -- José Abílio
Re: showstopper: cursor positioning with tables
On Wednesday 15 November 2006 1:29 pm, Edwin Leuven wrote: 1. new doc 2. insert a table 3. add some columns then try to put the cursor in one of the appended columns: this is not possible also not possible to put the cursor after the table I can confirm that, but since it does not crash lyx I will not consider it as a showstopper for the alpha version. -- José Abílio
Re: [PATCH] Optimize drawing
Jean-Marc Lasgouttes wrote: Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes: Abdelrazak IMO, optimizing LyX is a must for 1.5.0. Current drawing Abdelrazak strategy is really, *really*, complicated. So cleanups are Abdelrazak necessary in order to optimize it. I agree that we shall take the time to speed up 1.5. But you should make sure first that Jose will give you the time to do it well... The real problem is that I am not sure _I_ will find the time to it properly. But I am reasonably confident that (with enough time) we could achieve single line updates, including within insets. And this will be a huge improvement over 1.4 (which only has single paragraph updates outside of insets). Abdel.
Re: Preparing for alpha release
On Monday 13 November 2006 3:18 pm, Ozgur Ugras BARAN wrote: As nobody had reviewed the multi-index patch, I guess we will postpone it for 1.6 series, won't we? If you have the support of two other developers I will consider it. This is different from alpha 1 where there was necessary the endorsement of one other developer. OK? Ugras -- José Abílio
Re: showstopper: cursor positioning with tables
José Matos wrote: I can confirm that, but since it does not crash lyx I will not consider it as a showstopper for the alpha version. fine by me
Re: Preparing for alpha release
On Tuesday 14 November 2006 2:08 pm, Jean-Marc Lasgouttes wrote: Here is what I do these days for 1.4 releases. Thank you Jean-Marc, it helps a lot. :-) About version number: note that, with autoconf at least, if you name it anything else that 1.5.0svn or 1.5.0preN, the build system will default to configuring in stable mode (without debug and assertions). This may or may not be what you expect. It may be time to change that before release. Will something like this work? Index: config/lyxinclude.m4 === --- config/lyxinclude.m4(revision 15933) +++ config/lyxinclude.m4(working copy) @@ -16,7 +16,7 @@ else lyx_devel_version=no fi -if echo AC_PACKAGE_VERSION | grep 'pre' /dev/null ; then +if echo AC_PACKAGE_VERSION | grep -E 'pre|alpha' /dev/null ; then lyx_prerelease=yes JMarc -- José Abílio
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 13:44 schrieb Georg Baum:
Kornel Benko wrote:
Am Dienstag, 14. November 2006 21:46 schrieb Georg Baum:
Converted Extended-Insets.lyx looks now ok, but it still crashes here e.g.
on export-latex
For me it works. I guess you are on linux. Which version of gcc/libc? Can
you compile with debug info so that we can get line numbers in the
backtrace?
Finally it's there
Action is: export-Latex(plain)
Detaching after fork from child process 14874.
Detaching after fork from child process 14876.
Detaching after fork from child process 14878.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1087032608 (LWP 14220)]
0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
(gdb) bt
#0 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
#1 0x40bab5dc in iconv_close () from /lib/tls/libc.so.6
#2 0x08524d71 in ~IconvProcessor (this=0xbfffb3e4) at unicode.C:55
#3 0x08526d08 in ~pair (this=0xbfffb3e0) at unicode.C:284
#4 0x08525cff in lyx::ucs4_to_eightbit (ucs4str=0x8ea212c, ls=56, [EMAIL
PROTECTED]) at unicode.C:296
#5 0x081e28ed in lyx::(anonymous namespace)::TeXOnePar ([EMAIL PROTECTED],
[EMAIL PROTECTED], pit=
{std::_List_iterator_base = {_M_node = 0x8d16a80}, No data fields},
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at output_latex.C:493
#6 0x081e2fbe in lyx::latexParagraphs ([EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]) at output_latex.C:617
#7 0x08318395 in lyx::InsetText::latex (this=0x8d2b9f8, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at insettext.C:300
#8 0x082e98f9 in lyx::InsetFoot::latex (this=0x8d2b9f8, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at insetfoot.C:76
#9 0x081f3552 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars (this=0x8d2a738,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], c=2097153)
at paragraph_pimpl.C:519
#10 0x081e9df9 in lyx::Paragraph::simpleTeXOnePar (this=0x8d169d8, [EMAIL
PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at paragraph.C:1024
#11 0x081e1b3f in lyx::(anonymous namespace)::TeXOnePar ([EMAIL PROTECTED],
[EMAIL PROTECTED], pit=
{std::_List_iterator_base = {_M_node = 0x8d169d0}, No data fields},
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at output_latex.C:371
#12 0x081e2fbe in lyx::latexParagraphs ([EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]) at output_latex.C:617
#13 0x08318395 in lyx::InsetText::latex (this=0x8d2afe8, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at insettext.C:300
#14 0x082c5b6c in lyx::InsetBox::latex (this=0x8d2afe8, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at insetbox.C:353
#15 0x081f3552 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars (this=0x8d23cf8,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], c=2097153)
at paragraph_pimpl.C:519
...
The stack goes until level #49
...
As to your other questions:
1.) It is Linux 2.6.8-24.25
2.) rpm -q -f /lib/tls/libc.so.6
glibc-2.3.3-118
3.) rpm -q -f `which g++`
gcc-c++-3.3.4-11
Kornel
--
Kornel Benko
[EMAIL PROTECTED]
pgpOnJuDhhVYd.pgp
Description: PGP signature
Re: Crash in view-something with Extended-Insets.lyx
Kornel Benko wrote: Am Mittwoch, 15. November 2006 13:44 schrieb Georg Baum: Kornel Benko wrote: Am Dienstag, 14. November 2006 21:46 schrieb Georg Baum: Converted Extended-Insets.lyx looks now ok, but it still crashes here e.g. on export-latex For me it works. I guess you are on linux. Which version of gcc/libc? Can you compile with debug info so that we can get line numbers in the backtrace? Finally it's there Action is: export-Latex(plain) Detaching after fork from child process 14874. Detaching after fork from child process 14876. Detaching after fork from child process 14878. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087032608 (LWP 14220)] 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6 (gdb) bt #0 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6 #1 0x40bab5dc in iconv_close () from /lib/tls/libc.so.6 I think this is a problem of iconv on some platform. This has been reported by another person IIRC. Abdel.
[patch] TOC dialog
Following patch corrects some misbehavior in TOC dialog:
- When clicking on Toc insets, dialog switches to correct list.
- cursor goes to correct entry when clicked..
- some other fixes..
There is one strange problem, though. After clicking table toc
entries, cursor goes to correct table, but the last table inset is
selected in tableview. This only happens in the table insets. Any
idea?? This is no showstopper, in my opinion.
Then, may I ask somebody commits, if there is no problem??
Ugras
Index: QToc.C
===
--- QToc.C (revision 15933)
+++ QToc.C (working copy)
@@ -112,14 +112,24 @@
}
+int QToc::getType()
+{
+ return type_;
+}
+
+
void QToc::update()
{
- toc_models_.clear();
+ updateType();
+ updateToc();
+}
+
+void QToc::updateType()
+{
+
QStringList type_list;
- type_ = 0;
-
vectorstring const types = getTypes();
if (types.empty()) {
type_model_.setStringList(type_list);
@@ -127,8 +137,11 @@
return;
}
- string const selected_type = params().getCmdName();
- lyxerr[Debug::GUI] selected_type selected_type endl;
+ string selected_type ;
+ if(params()[type].empty()) //Then plain toc...
+ selected_type = params().getCmdName();
+ else
+ selected_type = to_ascii(params()[type]);
QString gui_names_;
for (size_t i = 0; i != types.size(); ++i) {
@@ -142,15 +155,21 @@
\ttoc_models_.size() toc_models_.size()
endl;
- toc_models_.push_back(new TocModel(getContents(types[i])));
}
type_model_.setStringList(type_list);
}
-void QToc::updateToc(int type)
+void QToc::updateToc()
{
- toc_models_[type] = new TocModel(getContents(getTypes()[type]));
+ toc_models_.clear();
+ vectorstring const types = getTypes();
+
+ for (size_t i = 0; i != types.size(); ++i) {
+
+ toc_models_.push_back(new TocModel(getContents(types[i])));
+ }
+
}
Index: QToc.h
===
--- QToc.h (revision 15933)
+++ QToc.h (working copy)
@@ -32,9 +32,11 @@
QToc(Dialog );
void update();
+ ///
+ void updateToc();
+ ///
+ void updateType();
- void updateToc(int type);
-
bool canOutline();
QStandardItemModel * tocModel();
@@ -47,6 +49,8 @@
QModelIndex const getCurrentIndex();
///
void goTo(QModelIndex const index);
+ ///
+ int getType();
private:
Index: QTocDialog.h
===
--- QTocDialog.h (revision 15933)
+++ QTocDialog.h (working copy)
@@ -71,6 +71,8 @@
protected:
///
void enableButtons(bool enable = true);
+ /// Reconnects the selection model change signal when TOC changed.
+ void reconnectSelectionModel();
private:
Index: QTocDialog.C
===
--- QTocDialog.C (revision 15933)
+++ QTocDialog.C (working copy)
@@ -79,7 +79,7 @@
void QTocDialog::on_updatePB_clicked()
{
- update();
+ form_-update();
}
@@ -105,6 +105,7 @@
{
form_-setTocModel(value);
tocTV-setModel(form_-tocModel());
+ reconnectSelectionModel();
enableButtons();
}
@@ -180,7 +181,7 @@
void QTocDialog::update()
{
- form_-update();
+ form_-updateToc();
updateGui();
}
@@ -197,6 +198,7 @@
}
typeCO-setModel(type_model);
+ typeCO-setCurrentIndex(form_-getType());
if (form_-tocModel())
tocTV-setModel(form_-tocModel());
@@ -208,12 +210,7 @@
tocTV-header()-setVisible(false);
enableButtons();
- connect(tocTV-selectionModel(),
- SIGNAL(currentChanged(const QModelIndex ,
- const QModelIndex )),
- this, SLOT(selectionChanged(const QModelIndex ,
- const QModelIndex )));
-
+ reconnectSelectionModel();
select(form_-getCurrentIndex());
lyxerr[Debug::GUI]
@@ -224,6 +221,16 @@
}
+void QTocDialog::reconnectSelectionModel()
+{
+ connect(tocTV-selectionModel(),
+ SIGNAL(currentChanged(const QModelIndex ,
+ const QModelIndex )),
+ this, SLOT(selectionChanged(const QModelIndex ,
+ const QModelIndex )));
+}
+
+
void QTocDialog::apply()
{
// Nothing to do here... for now.
@@ -239,7 +246,7 @@
void QTocDialog::show()
{
- update();
+ form_-update();
QDialog::show();
}
Re: Preparing for alpha release
José Matos wrote: On Tuesday 14 November 2006 2:08 pm, Jean-Marc Lasgouttes wrote: Here is what I do these days for 1.4 releases. Thank you Jean-Marc, it helps a lot. :-) About version number: note that, with autoconf at least, if you name it anything else that 1.5.0svn or 1.5.0preN, the build system will default to configuring in stable mode (without debug and assertions). This may or may not be what you expect. It may be time to change that before release. Will something like this work? Index: config/lyxinclude.m4 === --- config/lyxinclude.m4(revision 15933) +++ config/lyxinclude.m4(working copy) @@ -16,7 +16,7 @@ else lyx_devel_version=no fi -if echo AC_PACKAGE_VERSION | grep 'pre' /dev/null ; then +if echo AC_PACKAGE_VERSION | grep -E 'pre|alpha' /dev/null ; then lyx_prerelease=yes JMarc grep -E is not supported when running on Solaris. Use egrep instead... Stephan
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
José == José Matos [EMAIL PROTECTED] writes: Will the problem I just described be fixed with the help of obsoletedby? (And is it stored in the .lyx-file, so it doesn't matter if you saved the file in between). José I don't think so. What are describing would involve for each José paragraph to remember part of its history. José We have never been able to recover from such case. What we could do when a layout does not exist in a class is, instead of replacing it with defaultLayout(), to keep it as it is but let LyXTextClass::operator[] return defaultLayout for cases that do not exist. This would means that the layout name is not lost, but only not interpreted. JMarc
Re: Preparing for alpha release
On Wednesday 15 November 2006 3:19 pm, Stephan Witt wrote: grep -E is not supported when running on Solaris. Use egrep instead... I thought so, but I never remember which form is more universal. Does egrep has known problems? If not I will proceed with this change and do the release. Stephan -- José Abílio
Re: [patch] TOC dialog
Ozgur Ugras BARAN wrote: Following patch corrects some misbehavior in TOC dialog: - When clicking on Toc insets, dialog switches to correct list. - cursor goes to correct entry when clicked.. - some other fixes.. This looks good at first glance. There is one strange problem, though. After clicking table toc entries, cursor goes to correct table, but the last table inset is selected in tableview. This only happens in the table insets. Any idea?? This is no showstopper, in my opinion. Agreed. Then, may I ask somebody commits, if there is no problem?? I will do that once the first alpha is out. Thanks, Abdel.
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 16:12 schrieb Abdelrazak Younes:
Kornel Benko wrote:
Am Mittwoch, 15. November 2006 13:44 schrieb Georg Baum:
Kornel Benko wrote:
Am Dienstag, 14. November 2006 21:46 schrieb Georg Baum:
Converted Extended-Insets.lyx looks now ok, but it still crashes here e.g.
on export-latex
For me it works. I guess you are on linux. Which version of gcc/libc? Can
you compile with debug info so that we can get line numbers in the
backtrace?
Finally it's there
Action is: export-Latex(plain)
Detaching after fork from child process 14874.
Detaching after fork from child process 14876.
Detaching after fork from child process 14878.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1087032608 (LWP 14220)]
0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
(gdb) bt
#0 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
#1 0x40bab5dc in iconv_close () from /lib/tls/libc.so.6
I think this is a problem of iconv on some platform. This has been
reported by another person IIRC.
Maybe. I information about my environment may be interresting too.
For german (and ngerman) language I use in lib/languages:
...
german german Germanfalse iso8859-15 de_DE
ngerman ngerman German (new spelling) false iso8859-15 de_DE
...
(because of the Euro-sign)
Now, going up-stack, I see
(gdb) up
#4 0x08525cff in lyx::ucs4_to_eightbit (ucs4str=0x8ea212c, ls=56, [EMAIL
PROTECTED]) at unicode.C:296
296 processors.insert(std::make_pair(encoding, processor));
(gdb) print encoding
$3 = (const string ) @0x876ad14: {
static npos = 4294967295,
_M_dataplus = {
std::allocatorchar = {No data fields},
members of std::string::_Alloc_hider:
_M_p = 0x876a06c ISO-8859-15
},
static _S_empty_rep_storage = {0, 0, 2053, 0}
}
so there seems to be a relation to it.
Kornel
--
Kornel Benko
[EMAIL PROTECTED]
pgpRnLR3CD50G.pgp
Description: PGP signature
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wednesday 15 November 2006 3:21 pm, Jean-Marc Lasgouttes wrote: What we could do when a layout does not exist in a class is, instead of replacing it with defaultLayout(), to keep it as it is but let LyXTextClass::operator[] return defaultLayout for cases that do not exist. This would means that the layout name is not lost, but only not interpreted. Yes, it is one option. But it needs some work, we should warn about those paragraphs or else they will be easily forgoten. I do not disagree with your suggestion but it makes me a little suspicious about its usefulness... JMarc -- José Abílio
Re: [PATCH] Optimize drawing
On Nov 14, 2006, at 12:18 PM, Abdelrazak Younes wrote: Hello, Between two chunk of work, I've managed to finish the patch, so here it is. With this patch, when you click anywhere, including within nested text insets (not for mathed), there is no redrawing at _all_. This is an improvement over lyx-1.4 where the full screen were redrawn two times on each mouse click. I think this is a necessary improvement for Mac so, Jose, do you want it for this alpha or shall I wait until it is released? I think I have tested it enough already but I will understand if you'd like to wait. On the other hand, this is the typical feature that needs a lot of testing so the sooner users can test it, the better... you decide. Right now, I can't run LyX: it hangs in on reconfiguring. Here's the backtrace: Starting program: /Applications/LyX-150.app/Contents/MacOS/lyx Reading symbols for shared libraries .. . done LyX: reconfiguring user directory checking for a Latex2e program... +checking for pplatex... yes Program received signal SIGTRAP, Trace/breakpoint trap. 0x90029a6c in wait4 () (gdb) bt #0 0x90029a6c in wait4 () #1 0x90046d9b in system () #2 0x000f9249 in lyx::support::Systemcall::startscript (this=0xb65d, how=Wait, [EMAIL PROTECTED]) at systemcall.C:46 #3 0x0006167d in lyx::(anonymous namespace)::reconfigureUserLyXDir () at lyx_main.C:133 #4 0x00068121 in lyx::LyX::init (this=0xe317850) at lyx_main.C:718 #5 0x00068e39 in lyx::LyX::execBatchCommands (this=0xe317850, [EMAIL PROTECTED], argv=0xb9ec, [EMAIL PROTECTED]) at lyx_main.C:428 #6 0x00069670 in lyx::LyX::priv_exec (this=0xe317850, [EMAIL PROTECTED], argv=0xb9ec) at lyx_main.C:319 #7 0x00069bb2 in lyx::LyX::exec ([EMAIL PROTECTED], argv=0xb9ec) at lyx_main.C:171 #8 0x247d in main (argc=1, argv=0xb9ec) at main.C:46 Note also that it is still impossible to run LyX on Mac via the GUI (i.e., by double-clicking on the icon); only running via command line works. By the way, I haven't gotten profiling to work now that I've switched over to Intel Mac. Shark gives me a No samples taken. [CHUDDataSource] message. Any idea what I'm doing wrong? (I've also got my PPC Mac for a little while, yet. I'm compiling now, but it's slow.) Bennett
Re: Preparing for alpha release
José Matos wrote: On Wednesday 15 November 2006 3:19 pm, Stephan Witt wrote: grep -E is not supported when running on Solaris. Use egrep instead... I thought so, but I never remember which form is more universal. Does egrep has known problems? If not I will proceed with this change and do the release. AFAIK not. The (linux) man-page says that egrep is the same as grep -E. On Solaris grep -E works when using /usr/xpg4/bin/grep, BTW. But you cannot rely on having users /usr/xpg4/bin in front of /usr/bin in the PATH environment. Stephan --
Looking for developers who can give support for Multiple indices
As José indicated, I need support two (or more) other developers to add multiple index functionality for lyx 1.5. The development on my side is finished, what is necessary is to review the code add lyx2lyx stuff, and... a bit love of course.. :) For interested people, I have sent the diff two weeks ago. I can clean my working code and resend the patch. Ugras -- Forwarded message -- From: José Matos [EMAIL PROTECTED] Date: Nov 15, 2006 2:29 PM Subject: Re: Preparing for alpha release To: lyx-devel@lists.lyx.org On Monday 13 November 2006 3:18 pm, Ozgur Ugras BARAN wrote: As nobody had reviewed the multi-index patch, I guess we will postpone it for 1.6 series, won't we? If you have the support of two other developers I will consider it. This is different from alpha 1 where there was necessary the endorsement of one other developer. OK? Ugras -- José Abílio
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 16:24 schrieb Kornel Benko: ... Maybe. I information about my environment may be interresting too. For german (and ngerman) language I use in lib/languages: ... german german Germanfalse iso8859-15 de_DE ngerman ngerman German (new spelling) false iso8859-15 de_DE ... (because of the Euro-sign) After changing this entries to iso8859-1, there is no crash. Kornel -- Kornel Benko [EMAIL PROTECTED] pgppFTosRospO.pgp Description: PGP signature
Re: Crash in view-something with Extended-Insets.lyx
Kornel Benko wrote: Am Mittwoch, 15. November 2006 16:24 schrieb Kornel Benko: ... Maybe. I information about my environment may be interresting too. For german (and ngerman) language I use in lib/languages: ... german german Germanfalse iso8859-15 de_DE ngerman ngerman German (new spelling) false iso8859-15 de_DE ... (because of the Euro-sign) After changing this entries to iso8859-1, there is no crash. Good detective work! Abdel.
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
[EMAIL PROTECTED] wrote: Will the problem I just described be fixed with the help of obsoletedby? No. (And is it stored in the .lyx-file, so it doesn't matter if you saved the file in between). That problem should be covered by undo (but AFAIK it is not). Nothing should be stored in the .lyx file. Georg
Re: Preparing for alpha release
José == José Matos [EMAIL PROTECTED] writes: José On Tuesday 14 November 2006 2:08 pm, Jean-Marc Lasgouttes wrote: Here is what I do these days for 1.4 releases. José Thank you Jean-Marc, it helps a lot. :-) About version number: note that, with autoconf at least, if you name it anything else that 1.5.0svn or 1.5.0preN, the build system will default to configuring in stable mode (without debug and assertions). This may or may not be what you expect. It may be time to change that before release. José Will something like this work? I'd use case instead to avoid portability problems. Something like (untested) lyx_devel_version=no lyx_prerelease=no case AC_PACKAGE_VERSION in *svn*) lyx_devel_version=yes AC_DEFINE(DEVEL_VERSION, 1, [Define if you are building a development version of LyX]) LYX_DATE=not released yet echo WARNING: This is a development version. Expect bugs.;; *pre*|*alpha*)lyx_prerelease=yes echo WARNING: This is a prerelease. Be careful and backup your documents.;; esac But I suspect we'd better put alpha in the devel camp insetead of pre. Do as you prefer. BTW, at the same time, the following fix looks useful. JMarc Index: /afs/inria.fr/rocq/home/preval/lasgoutt/src/lyx/lyx-devel/config/lyxinclude.m4 === --- /afs/inria.fr/rocq/home/preval/lasgoutt/src/lyx/lyx-devel/config/lyxinclude.m4 (revision 15933) +++ /afs/inria.fr/rocq/home/preval/lasgoutt/src/lyx/lyx-devel/config/lyxinclude.m4 (working copy) @@ -195,7 +195,7 @@ AC_ARG_ENABLE(stdlib-debug, AC_ARG_ENABLE(concept-checks, AC_HELP_STRING([--enable-concept-checks],[enable concept checks]),, - [ if test $lyx_devel_version = yes -o $lyx-prerelease = yes ; then + [ if test $lyx_devel_version = yes -o $lyx_prerelease = yes ; then enable_concept_checks=yes; else enable_concept_checks=no;
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
José == José Matos [EMAIL PROTECTED] writes: José Yes, it is one option. But it needs some work, we should warn José about those paragraphs or else they will be easily forgoten. It was not an idea for 1.5 anyway. José I do not disagree with your suggestion but it makes me a José little suspicious about its usefulness... I do not know either, to be frank. It is just something that would be easy to do. JMarc
Re: Crash in view-something with Extended-Insets.lyx
Kornel Benko wrote:
Am Mittwoch, 15. November 2006 16:24 schrieb Kornel Benko:
...
Maybe. I information about my environment may be interresting too.
For german (and ngerman) language I use in lib/languages:
...
german german Germanfalse iso8859-15 de_DE
ngerman ngerman German (new spelling) false iso8859-15 de_DE
...
(because of the Euro-sign)
After changing this entries to iso8859-1, there is no crash.
From this I suspect that your iconv can't handle latin9. If that is true the
attached patch (which should go in anyway) should help, and you should also
see an error message on the console from iconv_open.
What I do not understand is why the german encoding plays a role. Does
Extended-insets.lyx contain german stuff?
GeorgIndex: src/support/unicode.C
===
--- src/support/unicode.C (Revision 15932)
+++ src/support/unicode.C (Arbeitskopie)
@@ -52,9 +52,11 @@ IconvProcessor::IconvProcessor(char cons
IconvProcessor::~IconvProcessor()
{
- if (iconv_close(pimpl_-cd) == -1) {
- lyxerr Error returned from iconv_close(
- errno ) endl;
+ if (pimpl_-cd != invalid_cd) {
+ if (iconv_close(pimpl_-cd) == -1) {
+ lyxerr Error returned from iconv_close(
+ errno ) endl;
+ }
}
delete pimpl_;
}
Re: Preparing for alpha release
On Wednesday 15 November 2006 4:03 pm, Jean-Marc Lasgouttes wrote: I'd use case instead to avoid portability problems. Something like (untested) lyx_devel_version=no lyx_prerelease=no case AC_PACKAGE_VERSION in *svn*) lyx_devel_version=yes AC_DEFINE(DEVEL_VERSION, 1, [Define if you are building a development version of LyX]) LYX_DATE=not released yet echo WARNING: This is a development version. Expect bugs.;; *pre*|*alpha*)lyx_prerelease=yes echo WARNING: This is a prerelease. Be careful and backup your documents.;; esac But I suspect we'd better put alpha in the devel camp insetead of pre. Do as you prefer. This looks nice. I will put it later, now I will leave for classes and I will finish the procedure when I return. BTW, at the same time, the following fix looks useful. Is the difference only whitespace? I compare the two lines and I don't see what is different. If you think it could be useful then commit it, please. JMarc -- José Abílio
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum: Kornel Benko wrote: Am Mittwoch, 15. November 2006 16:24 schrieb Kornel Benko: ... Maybe. I information about my environment may be interresting too. For german (and ngerman) language I use in lib/languages: ... german german Germanfalse iso8859-15 de_DE ngerman ngerman German (new spelling) false iso8859-15 de_DE ... (because of the Euro-sign) After changing this entries to iso8859-1, there is no crash. From this I suspect that your iconv can't handle latin9. If that is true the attached patch (which should go in anyway) should help, and you should also see an error message on the console from iconv_open. What I do not understand is why the german encoding plays a role. Does Extended-insets.lyx contain german stuff? Yes, there is german stuff as minipage example ... Your patch leads to: ... unicode.C: In destructor `lyx::IconvProcessor::~IconvProcessor()': unicode.C:55: error: ISO C++ forbids comparison between pointer and integer make[5]: *** [unicode.lo] Fehler 1 Kornel -- Kornel Benko [EMAIL PROTECTED] pgpC0scbkjoS1.pgp Description: PGP signature
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 17:25 schrieb Kornel Benko: Your patch leads to: Sorry, my failure Kornel -- Kornel Benko [EMAIL PROTECTED] pgp0hkuy4Xt1S.pgp Description: PGP signature
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum:
From this I suspect that your iconv can't handle latin9. If that is true the
attached patch (which should go in anyway) should help, and you should also
see an error message on the console from iconv_open.
It still crashes.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1087032608 (LWP 28978)]
0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
(gdb) bt
#0 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
#1 0x40bab5dc in iconv_close () from /lib/tls/libc.so.6
#2 0x08524d86 in ~IconvProcessor (this=0xbfffb3e4) at unicode.C:56
#3 0x08526d1c in ~pair (this=0xbfffb3e0) at unicode.C:286
#4 0x08525d13 in lyx::ucs4_to_eightbit (ucs4str=0x8ee953c, ls=56, [EMAIL
PROTECTED]) at unicode.C:298
#5 0x081e28ed in lyx::(anonymous namespace)::TeXOnePar ([EMAIL PROTECTED],
[EMAIL PROTECTED], pit=
{std::_List_iterator_base = {_M_node = 0x8d16f30}, No data fields},
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at output_latex.C:493
#6 0x081e2fbe in lyx::latexParagraphs ([EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]) at output_latex.C:617
#7 0x08318395 in lyx::InsetText::latex (this=0x8d2bd00, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at insettext.C:300
#8 0x082e98f9 in lyx::InsetFoot::latex (this=0x8d2bd00, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at insetfoot.C:76
#9 0x081f3552 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars (this=0x8d2bb30,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], c=2097153)
at paragraph_pimpl.C:519
#10 0x081e9df9 in lyx::Paragraph::simpleTeXOnePar (this=0x8d16e88, [EMAIL
PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at paragraph.C:1024
...
Kornel
--
Kornel Benko
[EMAIL PROTECTED]
pgppfotqcGSOb.pgp
Description: PGP signature
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wed, 15 Nov 2006, Jean-Marc Lasgouttes wrote: José I do not disagree with your suggestion but it makes me a little José suspicious about its usefulness... I do not know either, to be frank. It is just something that would be easy to do. I don't think it's too bad though. Here is another alternative. If it seems reasonable I can add it to bugzilla. How about inserting some special inset (or comment) in those paragraphs that don't have an equivalent in the new class? (The inset/comment would not produce any output). That comment/inset would then server as a reminder/warning that the paragraph layout wasn't properly converted. As an extension, there could be a method that when converting to a new document class looks in default paragraphs for such an inset. If the inset exists, the paragraph is converted to the original layout. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wed, 15 Nov 2006, Georg Baum wrote: (And is it stored in the .lyx-file, so it doesn't matter if you saved the file in between). That problem should be covered by undo (but AFAIK it is not). Nothing should be stored in the .lyx file. Why not (if it is done as I described in my other post just now)? /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Crash in view-something with Extended-Insets.lyx
Kornel Benko wrote: Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum: From this I suspect that your iconv can't handle latin9. If that is true the attached patch (which should go in anyway) should help, and you should also see an error message on the console from iconv_open. It still crashes. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087032608 (LWP 28978)] 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6 (gdb) bt #0 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6 #1 0x40bab5dc in iconv_close () from /lib/tls/libc.so.6 #2 0x08524d86 in ~IconvProcessor (this=0xbfffb3e4) at unicode.C:56 #3 0x08526d1c in ~pair (this=0xbfffb3e0) at unicode.C:286 #4 0x08525d13 in lyx::ucs4_to_eightbit (ucs4str=0x8ee953c, ls=56, [EMAIL PROTECTED]) at unicode.C:298 I see now: This is the problem. Inserting the new IconvProcessor into the map calls the copy constructor - iconv_close gets called twice for the same conversion descriptor. That means that IconvProcessor must not be copied. Abdel, do you have any idea how to solve that? We could implement our own copy constructor and assignment operator that opens a new decsripor, but I am not sure I like that. Basically we should be able to inherit from boost:noncopyable and never copy an IconvProcessor, but then we can not use a map. Georg
Re: Preparing for alpha release
José == José Matos [EMAIL PROTECTED] writes: José Is the difference only whitespace? I compare the two lines and José I don't see what is different. :) Think hyphen and underscore. José If you think it could be useful then commit it, please. I'll try to do it tomorrow. JMarc
Re: Crash in view-something with Extended-Insets.lyx
Georg Baum wrote: Kornel Benko wrote: Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum: From this I suspect that your iconv can't handle latin9. If that is true the attached patch (which should go in anyway) should help, and you should also see an error message on the console from iconv_open. It still crashes. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087032608 (LWP 28978)] 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6 (gdb) bt #0 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6 #1 0x40bab5dc in iconv_close () from /lib/tls/libc.so.6 #2 0x08524d86 in ~IconvProcessor (this=0xbfffb3e4) at unicode.C:56 #3 0x08526d1c in ~pair (this=0xbfffb3e0) at unicode.C:286 #4 0x08525d13 in lyx::ucs4_to_eightbit (ucs4str=0x8ee953c, ls=56, [EMAIL PROTECTED]) at unicode.C:298 I see now: This is the problem. Inserting the new IconvProcessor into the map calls the copy constructor - iconv_close gets called twice for the same conversion descriptor. That means that IconvProcessor must not be copied. Abdel, do you have any idea how to solve that? Maybe just remove the iconv_close in the destructor? This is not strictly needed I think and I put that just for clarity. We could implement our own copy constructor and assignment operator that opens a new decsripor, but I am not sure I like that. Basically we should be able to inherit from boost:noncopyable and never copy an IconvProcessor, but then we can not use a map. Whatever container we use the destructor will always be called on insertion, I think... If the iconv_close is really needed, we need just to do that explicitly when we need it instead of doing that in the destructor. Abdel.
Re: Crash in view-something with Extended-Insets.lyx
Kornel Benko wrote:
Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum:
From this I suspect that your iconv can't handle latin9. If that is true the
attached patch (which should go in anyway) should help, and you should also
see an error message on the console from iconv_open.
It still crashes.
Does this patch helps?
Abdel.
Index: src/support/unicode.C
===
--- src/support/unicode.C (revision 15933)
+++ src/support/unicode.C (working copy)
@@ -52,10 +52,6 @@
IconvProcessor::~IconvProcessor()
{
- if (iconv_close(pimpl_-cd) == -1) {
- lyxerr Error returned from iconv_close(
-errno ) endl;
- }
delete pimpl_;
}
Re: About the automatic vertical scrollbar in GuiWorkArea
Peter Kümmel wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter,
I think you did that change. Please revert it or fix it the proper way.
I'll revert, didn't know the proper way.
The proper way would be to hide it when there is no need to show it. We
can not rely on Qt automatic mode for this because we maintain our own
WorkArea.
But the scrolling bar is sooo ugly
I agree but that the small time lapse when the WorkArea is resized when
you switch buffers is even uglier.
I you want, you can disable it when there is no Buffer (in grayOut())...
or switching to always on when the scrollbar becomes visible the first time.
Is this a better solution? Means could I check it in?
I've checked it in, because it's totally uncritical:
Index: /lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C
===
--- /lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C (revision 15906)
+++ /lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C (revision 15935)
@@ -164,9 +164,9 @@
{
cursor_ = new frontend::CursorWidget();
cursor_-hide();
- setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOn);
+ setVerticalScrollBarPolicy(Qt::ScrollBarAsNeeded);
setHorizontalScrollBarPolicy(Qt::ScrollBarAlwaysOff);
setAcceptDrops(true);
setMinimumSize(100, 70);
@@ -217,8 +217,11 @@
void GuiWorkArea::setScrollbarParams(int h, int scroll_pos, int
scroll_line_step)
{
+ if (verticalScrollBarPolicy() != Qt::ScrollBarAlwaysOn)
+ setVerticalScrollBarPolicy(Qt::ScrollBarAlwaysOn);
+
verticalScrollBar()-setTracking(false);
// do what cursor movement does (some grey)
h += height() / 4;
@@ -516,8 +519,10 @@
void GuiWorkArea::doGreyOut(QLPainter pain)
{
+ setVerticalScrollBarPolicy(Qt::ScrollBarAsNeeded);
+
pain.fillRectangle(0, 0, width(), height(),
LColor::bottomarea);
//if (!lyxrc.show_banner)
Re: [PATCH] Optimize drawing
On Nov 15, 2006, at 10:29 AM, Bennett Helm wrote: On Nov 14, 2006, at 12:18 PM, Abdelrazak Younes wrote: Hello, Between two chunk of work, I've managed to finish the patch, so here it is. With this patch, when you click anywhere, including within nested text insets (not for mathed), there is no redrawing at _all_. This is an improvement over lyx-1.4 where the full screen were redrawn two times on each mouse click. I think this is a necessary improvement for Mac so, Jose, do you want it for this alpha or shall I wait until it is released? I think I have tested it enough already but I will understand if you'd like to wait. On the other hand, this is the typical feature that needs a lot of testing so the sooner users can test it, the better... you decide. Right now, I can't run LyX: it hangs in on reconfiguring. Here's the backtrace: False alarm. Something was messed up on my computer causing this problem; a restart fixed it. This is fine now. Speed in insets seems fine with the patch. (There are still some drawing issues with nested insets that existed even prior to the patch.) Note also that it is still impossible to run LyX on Mac via the GUI (i.e., by double-clicking on the icon); only running via command line works. This is still an issue. By the way, I haven't gotten profiling to work now that I've switched over to Intel Mac. Shark gives me a No samples taken. [CHUDDataSource] message. Any idea what I'm doing wrong? (I've also got my PPC Mac for a little while, yet. I'm compiling now, but it's slow.) ... And here I get a compilation error: if g++-dp-4.2 -DHAVE_CONFIG_H -I. -I. -I. -I../boost -Wextra - Wall-g -Os -MT ConverterCache.o -MD -MP -MF .deps/ ConverterCache.Tpo -c -o ConverterCache.o ConverterCache.C; \ then mv -f .deps/ConverterCache.Tpo .deps/ConverterCache.Po; else rm -f .deps/ConverterCache.Tpo; exit 1; fi ConverterCache.C:89: warning: 'lyx::ConverterCache::Impl' has a field 'lyx::ConverterCache::Impl::cache' whose type uses the anonymous namespace ConverterCache.C: In member function 'void lyx::ConverterCache::add (const std::string, const std::string, const std::string) const': ConverterCache.C:219: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope ConverterCache.C: In member function 'void lyx::ConverterCache::remove (const std::string, const std::string) const': ConverterCache.C:274: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope ConverterCache.C: In member function 'bool lyx::ConverterCache::inCache(const std::string, const std::string) const': ConverterCache.C:296: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope ConverterCache.C: In member function 'const std::string lyx::ConverterCache::cacheName(const std::string, const std::string) const': ConverterCache.C:323: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope ConverterCache.C: In member function 'bool lyx::ConverterCache::copy (const std::string, const std::string, const std::string) const': ConverterCache.C:338: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope make[3]: *** [ConverterCache.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Bennett
Re: [PATCH] Optimize drawing
Bennett Helm wrote: On Nov 15, 2006, at 10:29 AM, Bennett Helm wrote: On Nov 14, 2006, at 12:18 PM, Abdelrazak Younes wrote: Hello, Between two chunk of work, I've managed to finish the patch, so here it is. With this patch, when you click anywhere, including within nested text insets (not for mathed), there is no redrawing at _all_. This is an improvement over lyx-1.4 where the full screen were redrawn two times on each mouse click. I think this is a necessary improvement for Mac so, Jose, do you want it for this alpha or shall I wait until it is released? I think I have tested it enough already but I will understand if you'd like to wait. On the other hand, this is the typical feature that needs a lot of testing so the sooner users can test it, the better... you decide. Right now, I can't run LyX: it hangs in on reconfiguring. Here's the backtrace: False alarm. Something was messed up on my computer causing this problem; a restart fixed it. This is fine now. Speed in insets seems fine with the patch. (There are still some drawing issues with nested insets that existed even prior to the patch.) Nice to hear that there is some progress in the right direction. Note also that it is still impossible to run LyX on Mac via the GUI (i.e., by double-clicking on the icon); only running via command line works. This is still an issue. By the way, I haven't gotten profiling to work now that I've switched over to Intel Mac. Shark gives me a No samples taken. [CHUDDataSource] message. Any idea what I'm doing wrong? (I've also got my PPC Mac for a little while, yet. I'm compiling now, but it's slow.) ... And here I get a compilation error: Is fixed in svn now. if g++-dp-4.2 -DHAVE_CONFIG_H -I. -I. -I. -I../boost -Wextra -Wall -g -Os -MT ConverterCache.o -MD -MP -MF .deps/ConverterCache.Tpo -c -o ConverterCache.o ConverterCache.C; \ then mv -f .deps/ConverterCache.Tpo .deps/ConverterCache.Po; else rm -f .deps/ConverterCache.Tpo; exit 1; fi ConverterCache.C:89: warning: 'lyx::ConverterCache::Impl' has a field 'lyx::ConverterCache::Impl::cache' whose type uses the anonymous namespace ConverterCache.C: In member function 'void lyx::ConverterCache::add(const std::string, const std::string, const std::string) const': ConverterCache.C:219: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope ConverterCache.C: In member function 'void lyx::ConverterCache::remove(const std::string, const std::string) const': ConverterCache.C:274: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope ConverterCache.C: In member function 'bool lyx::ConverterCache::inCache(const std::string, const std::string) const': ConverterCache.C:296: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope ConverterCache.C: In member function 'const std::string lyx::ConverterCache::cacheName(const std::string, const std::string) const': ConverterCache.C:323: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope ConverterCache.C: In member function 'bool lyx::ConverterCache::copy(const std::string, const std::string, const std::string) const': ConverterCache.C:338: error: 'BOOST_CURRENT_FUNCTION' was not declared in this scope make[3]: *** [ConverterCache.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Bennett -- Peter Kümmel
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 18:43 schrieb Abdelrazak Younes: Kornel Benko wrote: Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum: From this I suspect that your iconv can't handle latin9. If that is true the attached patch (which should go in anyway) should help, and you should also see an error message on the console from iconv_open. It still crashes. Does this patch helps? Unfortunatelly I cannot test right now :( One of my harddiscs is going mad. Kornel -- Kornel Benko [EMAIL PROTECTED] pgpBslTQZJdTQ.pgp Description: PGP signature
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 18:43 schrieb Abdelrazak Younes: Kornel Benko wrote: Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum: From this I suspect that your iconv can't handle latin9. If that is true the attached patch (which should go in anyway) should help, and you should also see an error message on the console from iconv_open. It still crashes. Does this patch helps? No, it still crashes. And you commented the code already. :) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087020320 (LWP 23866)] 0x40ba8dc9 in __gconv () from /lib/tls/libc.so.6 (gdb) bt #0 0x40ba8dc9 in __gconv () from /lib/tls/libc.so.6 #1 0x40ba84ba in iconv () from /lib/tls/libc.so.6 #2 0x08524f4d in lyx::IconvProcessor::convert () #3 0x08526337 in lyx::(anonymous namespace)::iconv_convertchar, wchar_t () #4 0x08525d13 in lyx::ucs4_to_eightbit () #5 0x081e294d in lyx::(anonymous namespace)::TeXOnePar () #6 0x081e301e in lyx::latexParagraphs () #7 0x083183f5 in lyx::InsetText::latex () #8 0x082e9959 in lyx::InsetFoot::latex () #9 0x081f35b2 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars () #10 0x081e9e59 in lyx::Paragraph::simpleTeXOnePar () #11 0x081e1b9f in lyx::(anonymous namespace)::TeXOnePar () #12 0x081e301e in lyx::latexParagraphs () #13 0x083183f5 in lyx::InsetText::latex () #14 0x082c5bcc in lyx::InsetBox::latex () #15 0x081f35b2 in lyx::Paragraph::Pimpl::simpleTeXSpecialChars () #16 0x081e9e59 in lyx::Paragraph::simpleTeXOnePar () #17 0x081e1b9f in lyx::(anonymous namespace)::TeXOnePar () #18 0x081e301e in lyx::latexParagraphs () #19 0x080ddd6e in lyx::Buffer::writeLaTeXSource () #20 0x080dd0dd in lyx::Buffer::makeLaTeXFile () #21 0x0813f933 in lyx::Exporter::Export () ... Kornel P.S. I am unable to produce debug version here. -- Kornel Benko [EMAIL PROTECTED] pgp8cbDzgXuwe.pgp Description: PGP signature
Re: [PATCH] Optimize drawing
On Nov 15, 2006, at 1:52 PM, Peter Kümmel wrote: Bennett Helm wrote: False alarm. Something was messed up on my computer causing this problem; a restart fixed it. This is fine now. Speed in insets seems fine with the patch. (There are still some drawing issues with nested insets that existed even prior to the patch.) Nice to hear that there is some progress in the right direction. Note also that it is still impossible to run LyX on Mac via the GUI (i.e., by double-clicking on the icon); only running via command line works. This is still an issue. By the way, I haven't gotten profiling to work now that I've switched over to Intel Mac. Shark gives me a No samples taken. [CHUDDataSource] message. Any idea what I'm doing wrong? (I've also got my PPC Mac for a little while, yet. I'm compiling now, but it's slow.) ... And here I get a compilation error: Is fixed in svn now. Yes. Speed in insets is no longer a special problem on PPC Mac (though speed improvements generally would be welcome). I'll post a profile from PPC Mac soon. Bennett
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 18:22 schrieb Abdelrazak Younes:
Georg Baum wrote:
Kornel Benko wrote:
Am Mittwoch, 15. November 2006 17:09 schrieb Georg Baum:
From this I suspect that your iconv can't handle latin9. If that is
true
the attached patch (which should go in anyway) should help, and you
should also see an error message on the console from iconv_open.
It still crashes.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1087032608 (LWP 28978)]
0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
(gdb) bt
#0 0x40babf4d in __gconv_close () from /lib/tls/libc.so.6
#1 0x40bab5dc in iconv_close () from /lib/tls/libc.so.6
#2 0x08524d86 in ~IconvProcessor (this=0xbfffb3e4) at unicode.C:56
#3 0x08526d1c in ~pair (this=0xbfffb3e0) at unicode.C:286
#4 0x08525d13 in lyx::ucs4_to_eightbit (ucs4str=0x8ee953c, ls=56,
[EMAIL PROTECTED]) at unicode.C:298
I see now: This is the problem. Inserting the new IconvProcessor into
the
map calls the copy constructor - iconv_close gets called twice for the
same conversion descriptor.
That means that IconvProcessor must not be copied. Abdel, do you have
any
idea how to solve that?
Maybe just remove the iconv_close in the destructor? This is not
strictly needed I think and I put that just for clarity.
It should be called to free up system resources. I found a very elegant way
to solve the
We could implement our own copy constructor and
assignment operator that opens a new decsripor, but I am not sure I
like
that. Basically we should be able to inherit from boost:noncopyable and
never copy an IconvProcessor, but then we can not use a map.
Whatever container we use the destructor will always be called on
insertion, I think...
Yes.
If the iconv_close is really needed, we need just to do that explicitly
when we need it instead of doing that in the destructor.
I was finally able to reproduce Kornels problems with a document with three
encodings (only two did not shopw any problem here). The problem is more
fundamental: pimpl_ is deleted twice (because the compiler generated copy
constructor does not call new). So in addition to the problem I wanted to
solve with my first patch we have another one that occurs if iconv_close
is not called.
The attached patch solves the destruction problem, too. It works fine for
me, and I also know why.
José, if you did not already roll the alpha release I'd suggest to include
it. It is safe enough IMO, and documents with other inputenc than utf8 are
very likely to crash LyX without the patch. On Mac it seems that the
probability is 100%.
Georg
Index: src/support/unicode.C
===
--- src/support/unicode.C (Revision 15936)
+++ src/support/unicode.C (Arbeitskopie)
@@ -39,6 +39,15 @@ static const iconv_t invalid_cd = (iconv
struct IconvProcessor::Private {
Private(): cd(invalid_cd) {}
+ ~Private()
+ {
+ if (cd != invalid_cd) {
+ if (iconv_close(cd) == -1) {
+lyxerr Error returned from iconv_close(
+errno ) endl;
+ }
+ }
+ }
iconv_t cd;
};
@@ -50,16 +59,27 @@ IconvProcessor::IconvProcessor(char cons
}
-IconvProcessor::~IconvProcessor()
+IconvProcessor::IconvProcessor(IconvProcessor const other)
+ : tocode_(other.tocode_), fromcode_(other.fromcode_),
+ pimpl_(new IconvProcessor::Private)
{
- if (iconv_close(pimpl_-cd) == -1) {
- lyxerr Error returned from iconv_close(
- errno ) endl;
- }
- delete pimpl_;
}
+IconvProcessor IconvProcessor::operator=(IconvProcessor const other)
+{
+ if (other == this)
+ return *this;
+ tocode_ = other.tocode_;
+ fromcode_ = other.fromcode_;
+ pimpl_.reset(new Private);
+ return *this;
+}
+
+
+IconvProcessor::~IconvProcessor() {}
+
+
bool IconvProcessor::init()
{
if (pimpl_-cd != invalid_cd)
Index: src/support/unicode.h
===
--- src/support/unicode.h (Revision 15936)
+++ src/support/unicode.h (Arbeitskopie)
@@ -15,6 +15,8 @@
#include support/types.h
+#include boost/scoped_ptr.hpp
+
#include string
#include vector
@@ -27,6 +29,12 @@ public:
IconvProcessor(
char const * tocode = ,
char const * fromcode = );
+ /// copy constructor needed because of pimpl_
+ IconvProcessor(IconvProcessor const );
+ /// assignment operator needed because of pimpl_
+ IconvProcessor operator=(IconvProcessor const );
+ /// destructor (needs to be implemented in the .C file because the
+ /// boost::scoped_ptr destructor needs a fully defined type
~IconvProcessor();
/// convert any data from \c fromcode to \c tocode unicode format.
@@ -45,7 +53,7 @@ private:
std::string fromcode_;
struct Private;
- Private * pimpl_;
+ boost::scoped_ptrPrivate pimpl_;
};
// utf8_to_ucs4
Re: Crash in view-something with Extended-Insets.lyx
On Wednesday 15 November 2006 9:13 pm, Georg Baum wrote: José, if you did not already roll the alpha release I'd suggest to include it. It is safe enough IMO, and documents with other inputenc than utf8 are very likely to crash LyX without the patch. On Mac it seems that the probability is 100%. Put it in, please. :-) Georg -- José Abílio
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 22:29 schrieb José Matos: Put it in, please. :-) Done. I was about to go offline, your email came just in time :-) Georg
Re: change tracking icons
Leuven, E. wrote: i played a bit around and the results are here: http://leuven.ecodip.net/lyx/changes.zip opinions/suggestions? The icons look nice but IMHO the current icon set is more intuitive. For instance, the icons for all-changes-accept/all-changes-reject have a pointer (arrow) which I interpret as change-next. OTOH, the icon for change-next has no such pointer. Michael
Re: Preparing for alpha release
On Wednesday 15 November 2006 5:09 pm, Jean-Marc Lasgouttes wrote: :) Think hyphen and underscore. Now, that helps to understand the change. :-) José If you think it could be useful then commit it, please. I'll try to do it tomorrow. Since I understood the fix I applied it myself. JMarc -- José Abílio
Re: Crash in view-something with Extended-Insets.lyx
On Wednesday 15 November 2006 9:41 pm, Georg Baum wrote: Am Mittwoch, 15. November 2006 22:29 schrieb José Matos: Put it in, please. :-) Done. I was about to go offline, your email came just in time :-) Thank you. :-) Georg -- José Abílio
Re: Preparing for alpha release
On Wednesday 15 November 2006 4:03 pm, Jean-Marc Lasgouttes wrote: I'd use case instead to avoid portability problems. Something like (untested) lyx_devel_version=no lyx_prerelease=no case AC_PACKAGE_VERSION in *svn*) lyx_devel_version=yes AC_DEFINE(DEVEL_VERSION, 1, [Define if you are building a development version of LyX]) LYX_DATE=not released yet echo WARNING: This is a development version. Expect bugs.;; *pre*|*alpha*)lyx_prerelease=yes echo WARNING: This is a prerelease. Be careful and backup your documents.;; esac I like this, and it removes 4 lines, this code is more readable so I have replaced. Since it works in my tests I have committed it. But I suspect we'd better put alpha in the devel camp insetead of pre. Do as you prefer. I prefer the code this way. :-) An alpha release is a release candidate in disguise. ;-) JMarc -- José Abílio
Re: Crash in view-something with Extended-Insets.lyx
Am Mittwoch, 15. November 2006 22:50 schrieb José Matos: On Wednesday 15 November 2006 9:41 pm, Georg Baum wrote: Am Mittwoch, 15. November 2006 22:29 schrieb José Matos: Put it in, please. :-) Done. I was about to go offline, your email came just in time :-) Thank you. :-) I can confirm that this is not crashing anymore :) I have _new_ crash with the same lyx-file, but with page-up though. Kornel -- Kornel Benko [EMAIL PROTECTED] pgptoRnzGMrmr.pgp Description: PGP signature
LyX 1.4.3-5 (Windows) and the Law of Unintended Consequences
I just installed 1.4.3-5 (over 1.4.3-4) and discovered a new behavior that I assume is by design. Formerly the default icon ran lyx.bat, which in turn started lyx.exe. Now the icon runs lyx.exe, which apparently writes a temporary file (something.tmp) that in turn runs lyxc.exe. Well, some of us run personal firewalls (ZoneAlarm in my case) on our PCs. Every time I start LyX now, ZoneAlarm needs me to bless it, because a temp file starting another program is (rightly) deemed suspicious. Better still, I can tell ZoneAlarm to remember permissions I grant (so that I don't get asked again), but since the temp file changes each time, this won't work. Every time I start LyX, I need to give ZA an 'OK' response. Not horrible (it's just one more click), but a tad tedious. /Paul
Message translation
Georg, all, is this a proper use of to_ascii? Michael Index: qt4/GuiWorkArea.C === --- qt4/GuiWorkArea.C (Revision 15938) +++ qt4/GuiWorkArea.C (Arbeitskopie) @@ -18,6 +18,7 @@ #include QLyXKeySym.h #include qt_helpers.h +#include gettext.h #include LyXView.h #include BufferView.h @@ -529,7 +530,7 @@ // return; lyxerr show banner: lyxrc.show_banner endl; /// The text to be written on top of the pixmap - string const text = lyx_version ? lyx_version : unknown; + string const text = lyx_version ? lyx_version : to_ascii(_(version unknown)); string const file = support::libFileSearch(images, banner, ppm); if (file.empty()) return;
Crash with Page-up
1.) Open Extended-Insets.lyx 2.) Go to the end 3.) repeat page up until crash (I had to repeat 9 times) My Screendisplay is about 24x80 characters Oh shit ... changing the window-size, it is more dificult to reproduce the crash ... This time with gdb: Program received signal SIGABRT, Aborted. [Switching to Thread 1087020320 (LWP 5165)] 0xe410 in ?? () #0 0xe410 in ?? () #1 0xbfffcd98 in ?? () #2 0x0006 in ?? () #3 0x142d in ?? () #4 0x40bb9d41 in raise () from /lib/tls/libc.so.6 #5 0x40bbb529 in abort () from /lib/tls/libc.so.6 #6 0x084fb593 in lyx::support::abort () #7 0x080d5ede in boost::assertion_failed () #8 0x08130d66 in lyx::CoordCache::get () #9 0x0822f12a in lyx::LyXText::getRowNearY () #10 0x0822f35c in lyx::LyXText::editXY () #11 0x0822fb8a in lyx::LyXText::cursorUp () #12 0x082315cc in lyx::LyXText::cursorPrevious () #13 0x082329fe in lyx::LyXText::dispatch () #14 0x083181a2 in lyx::InsetText::doDispatch () #15 0x082bc0a9 in lyx::InsetBase::dispatch () #16 0x081326d3 in lyx::LCursor::dispatch () #17 0x0819a541 in lyx::LyXFunc::dispatch () #18 0x0818efd7 in lyx::LyXFunc::processKeySym () #19 0x0834e311 in lyx::frontend::WorkArea::processKeySym () #20 0x083b2001 in lyx::frontend::GuiWorkArea::keyPressEvent () #21 0x401718db in QWidget::event () from /usr/local/Trolltech/Qt-4.1.4/lib/libQtGui.so.4 #22 0x4037d2f0 in QFrame::event () from /usr/local/Trolltech/Qt-4.1.4/lib/libQtGui.so.4 #23 0x403f8a6d in QAbstractScrollArea::event () from /usr/local/Trolltech/Qt-4.1.4/lib/libQtGui.so.4 #24 0x4012f302 in QApplicationPrivate::notify_helper () from /usr/local/Trolltech/Qt-4.1.4/lib/libQtGui.so.4 #25 0x4012fcfb in QApplication::notify () from /usr/local/Trolltech/Qt-4.1.4/lib/libQtGui.so.4 ... so, now I had to use the repeat-feature of the page-up key (it may have been 50 or so page-ups) Kornel -- Kornel Benko [EMAIL PROTECTED] pgpK8vVZlF9Aa.pgp Description: PGP signature
LyX 1.5.0 - alpha 1 (Ruby) is out
Hi, I have followed the wise steps described by Lars and Jean-Marc to make a release (*). I have placed the resulting packages in http://www.lyx.org/~jamatos/ Please test them before I make a broader announce. If all is working, as expected, I will write the announce, with references to http://wiki.lyx.org/LyX/KnownBugsInLyX15 http://wiki.lyx.org/LyX/NewInLyX15 (*) Any errors in packaging are my fault. Best regards, -- José Abílio
1.5.0 alpha crash on quit
1.5.0 alpha crashes every time on quit on Intel Mac. Here's the backtrace: Program received signal SIGABRT, Aborted. 0x9003d1dc in kill () (gdb) bt #0 0x9003d1dc in kill () #1 0x9010f2af in raise () #2 0x9010de02 in abort () #3 0x90b4039c in __gnu_cxx::__verbose_terminate_handler () #4 0x90b3e602 in __gxx_personality_v0 () #5 0x90b3e640 in std::terminate () #6 0x90b3ea93 in __cxa_pure_virtual () #7 0x0008f5de in lyx::LyXServerSocket::~LyXServerSocket (this=0xe3be3d0) at lyxsocket.C:80 #8 0x0066d27a in boost::checked_deletelyx::LyXServerSocket (x=0xe3be3d0) at ../boost/boost/checked_delete.hpp:34 #9 0x0066ef11 in lyx::LyX::Singletons::~Singletons (this=0xe317860) at ../boost/boost/scoped_ptr.hpp:77 #10 0x0066efaa in boost::checked_deletelyx::LyX::Singletons (x=0xe317860) at ../boost/boost/checked_delete.hpp:34 #11 0x0066efd6 in lyx::LyX::~LyX (this=0xe317850) at ../boost/boost/ scoped_ptr.hpp:77 #12 0x0066f01a in boost::checked_deletelyx::LyX (x=0xe317850) at ../ boost/boost/checked_delete.hpp:34 #13 0x0006466b in __static_initialization_and_destruction_0 (__initialize_p=0, __priority=-1878797860) at ../boost/boost/ scoped_ptr.hpp:77 #14 0x8fe0e32d in __dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkContex tE () #15 0x8fe030ec in __dyld__ZN4dyld14runTerminatorsEv () #16 0x9000ff5c in __cxa_finalize () #17 0x9000fe58 in exit () #18 0x1f0e in _start (argc=1, argv=0xba04, envp=0xba0c) at /SourceCache/Csu/Csu-58/crt.c:272 #19 0x1e21 in start () Bennett
1.5.0 alpha crash on close buffer
1.5.0-alpha crashes on closing a buffer on Intel Mac. Recipe: Start LyX. File New; File Close. Here's the backtrace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x001d0505 in QFont::QFont () at QLImage.C:172 172 } (gdb) bt #0 0x001d0505 in QFont::QFont () at QLImage.C:172 #1 0x0032b3cf in QPainter::setFont () at GraphicsCacheItem.C:194 #2 0x0030419a in lyx::frontend::GuiWorkArea::doGreyOut (this=0xe364df0, [EMAIL PROTECTED]) at GuiWorkArea.C:561 #3 0x00304448 in lyx::frontend::GuiWorkArea::expose (this=0xe364df0, x=1, y=1, w=1, h=1) at GuiWorkArea.C:586 #4 0x001b2499 in lyx::frontend::WorkArea::redraw (this=0xe364e04, singlePar=0) at WorkArea.C:139 #5 0x001b23c2 in lyx::frontend::WorkArea::resizeBufferView (this=0xe364e04) at WorkArea.C:223 #6 0x0030371a in lyx::frontend::GuiWorkArea::resizeEvent (this=0xe364df0, ev=0xbfffd5c4) at GuiWorkArea.C:510 #7 0x001ea651 in QWidget::event () at QLImage.C:172 #8 0x0023f6a4 in QFrame::event () at Dialogs.C:320 #9 0x0022463f in QAbstractScrollArea::viewportEvent () at Dialogs.C:320 #10 0x006ed036 in QAbstractScrollAreaPrivate::viewportEvent () at fileiter.cpp:214 #11 0x006ed066 in QAbstractScrollAreaFilter::eventFilter () at fileiter.cpp:214 #12 0x00168bfc in QApplicationPrivate::notify_helper () at insetspecialchar.C:65 #13 0x0016ecd3 in QApplication::notify () at insetspecialchar.C:65 #14 0x0028b783 in QWidgetPrivate::setGeometry_sys () at Dialogs.C:320 #15 0x001e9cc6 in QWidget::setGeometry () at QLImage.C:172 #16 0x00225ebe in QAbstractScrollAreaPrivate::layoutChildren () at Dialogs.C:320 #17 0x00303d56 in lyx::frontend::GuiWorkArea::doGreyOut (this=0xe364df0, [EMAIL PROTECTED]) at GuiWorkArea.C:523 #18 0x00304448 in lyx::frontend::GuiWorkArea::expose (this=0xe364df0, x=1, y=1, w=1, h=1) at GuiWorkArea.C:586 #19 0x001b2499 in lyx::frontend::WorkArea::redraw (this=0xe364e04, singlePar=0) at WorkArea.C:139 #20 0x006b4de7 in boost::_bi::bind_tvoid, boost::_mfi::mf1void, lyx::LyXView, lyx::Buffer*, boost::_bi::list2boost::_bi::valuelyx::LyXView*, boost::_bi::valuelyx::Buffer* ::operator() (this=0x1a2885c0) at ../../boost/boost/bind/bind_template.hpp:20 #21 0x00641aab in boost::function0void, std::allocatorvoid ::operator() (this=0x1a2885a4) at ../boost/boost/function/ function_template.hpp:692 #22 0x00641acc in boost::signals::detail::call_bound0void::callerboost::functionvoid ( )(), std::allocatorvoid ::operator() boost::signals::detail::connection_slot_pair (this=0xbfffdc64, [EMAIL PROTECTED]) at ../boost/boost/signals/signal_template.hpp:119 #23 0x00642e09 in boost::signals::detail::slot_call_iteratorboost::signals::detail::call_ bound0void::callerboost::functionvoid ()(), std::allocatorvoid , boost::signals::detail::named_slot_map_iterator::dereference (this=0xbfffdc44) at ../boost/boost/signals/detail/ slot_call_iterator.hpp:61 #24 0x00647faa in boost::operator+ +boost::signals::detail::slot_call_iteratorboost::signals::detail::cal l_bound0void::callerboost::functionvoid ()(), std::allocatorvoid , boost::signals::detail::named_slot_map_iterator, boost::signals::detail::unusable, boost::single_pass_traversal_tag, boost::signals::detail::unusable const, int ([EMAIL PROTECTED]) at ../ boost/boost/iterator/iterator_facade.hpp:144 #25 0x006480c8 in boost::last_valuevoid::operator() boost::signals::detail::slot_call_iteratorboost::signals::detail::call _bound0void::callerboost::functionvoid ()(), std::allocatorvoid , boost::signals::detail::named_slot_map_iterator (this=0x1a25f8e4, [EMAIL PROTECTED], [EMAIL PROTECTED]) at ../boost/ boost/last_value.hpp:43 #26 0x0064cbe9 in boost::signal0void, boost::last_valuevoid, int, std::lessint, boost::functionvoid ()(), std::allocatorvoid ::operator() (this=0x1a2612dc) at ../boost/boost/signals/ signal_template.hpp:354 #27 0x00027a60 in lyx::Buffer::~Buffer (this=0x1a261250) at buffer.C:230 #28 0x0003566f in lyx::BufferList::release (this=0xe317888, buf=0x1a261250) at bufferlist.C:154 #29 0x000369f7 in lyx::BufferList::close (this=0xe317888, buf=0x1a261250, ask=1) at bufferlist.C:183 #30 0x0006f416 in lyx::LyXFunc::closeBuffer (this=0xe317860) at lyxfunc.C:2005 #31 0x00075258 in lyx::LyXFunc::dispatch (this=0xe317860, [EMAIL PROTECTED]) at lyxfunc.C:833 #32 0x0007ca35 in lyx::LyXFunc::processKeySym (this=0xe317860, [EMAIL PROTECTED], state=ctrl) at lyxfunc.C:341 #33 0x001b2b8b in lyx::frontend::WorkArea::processKeySym (this=0xe364e04, [EMAIL PROTECTED], state=ctrl) at WorkArea.C:175 #34 0x0030537f in lyx::frontend::GuiWorkArea::keyPressEvent (this=0xe364df0, e=0xbfffecfc) at GuiWorkArea.C:446 #35 0x001ea752 in QWidget::event () at QLImage.C:172 #36 0x0023f6a4 in QFrame::event () at Dialogs.C:320 #37 0x0022724b in QAbstractScrollArea::event () at Dialogs.C:320 #38 0x00168c48 in QApplicationPrivate::notify_helper () at insetspecialchar.C:65
Re: Message translation
Michael Gerz wrote: Georg, all, is this a proper use of to_ascii? No. The translated string could contain non-ascii characters. The result of _() should always be run through to_utf8() if it is needed as a std::string. If there are cases where it is known that the result of _() is always pure ascii I doubt that the translation is needed at all. - string const text = lyx_version ? lyx_version : unknown; + string const text = lyx_version ? lyx_version : to_ascii(_(version unknown)); Why not + QString const text = lyx_version ? QString(lyx_version) : qt_(version unknown); and remove the toqstr() lateron? Or if the result would not be needed as a QString I'd rather convert it to a docstring. Georg
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
On Wed, 15 Nov 2006, Abdelrazak Younes wrote: > > > > perhaps 'M-s', to this action (combined with a separate GUI button)? > > > We already have Alt-M-s and that's fine. But I would like something even > > > simpler than that. > > > > What the heck does 'Alt-M-s' mean? Or do you mean 'M-p s'? > > (I thought Alt and Meta was the same key...) > > Yep typo, sorry, I really meant Alt+p s No worries, I just got confused :-) Actually it'd be quite funny to see a new (Windows) user try and find the combination 'Alt-M-s'... In another post, Jean-Marc wrote: > Georg> I have added a button to my toolbar to do this. It is not 100% > Georg> fool proof (because it uses layout Standard, and the default > Georg> layout is named differently in some classes), but for me it is > Georg> OK. > > We could decide that layout-paragraph without argument sets layout to > default. Jean-Marc, do you really mean 'layout-paragraph'? Fiddling a bit I thought it was 'layout' that changes the layout. Using 'layout-paragraph' brings up a dialog. I'll assume it is 'layout' in what I write below. I'll try to summarize the different alternatives discussed in this thread: Currently available alternatives: * Use keyboard shortcut 'M-p s' * Use 'M-x layout Standard', i.e * Use the pull-down list with environments and select Standard I *think* that an (expert) user can currently also configure his system a bit so the followin alternatives also become available: * Bind a command-sequence to e.g. M-C-s that invokes 'layout Standard' using: \bind "M-C-s" "command-sequence layout Standard;" * Create a toolbar button for this purpose by creating and icon with the name (?) "command-sequence layout Standard;" and place it in the directory ??. LyX will then execute the command when the user clicks on the icon. (Is this how you do it, I don't remember!) Any of the "expert" alternatives above could of course be made to work in a new release of a LyX by default. New suggestions and alternatives: * new-1 (Andreas): Click "Decrease depth" buton and if on the first level, (and in Itemize/Enumerate/Descirption/List), the environment changes to Standard. ** Make it work only for Itemize/Enumerate that is not followed by any text, i.e. for * but not for * text... * new-2 (Abdel): If the paragraph is empty, switches to Standard instead of deleting the paragraph. (In order to delete a paragraph you have to press twice). * new-3 (JMarc): Make 'layout' without argument set the paragraph to Standard (or whatever the standard paragraph type is called). This makes it easier to get a button to work in all types of document. * new-4 (JMarc): "kill break-paragraph-keep-layout (M-Return) and recycle the binding to a new break-paragraph-reset-layout that would: - insert a paragraph break - reduce depth by one - set the layout to the one of the enclosing nesting (think enumerate in itemize) or the standard layout at depth 0. I think the resetting at the time of a paragraph break is better than after the fact." (Note: I didn't get this bit...) * new-5 (Abdel): Extend the dEPM mechanism: Typing return twice after a list or an enumeration automatically switches the paragraph layout to "Standard". I think that we should do the following: * Do 'new-3', i.e. let 'layout' without argument set the paragraph layout to "Standard" * Create an (optional?) toolbar button for changing to "Standard" If we in addition should do something, I think that 'new-5' sounds interesting, i.e. return twice after a list changes to Standard. cheers /Christian PS. I discovered that the argument of the LFUN layout is case sensitive. In other words, 'layout Standard' works but 'layout standard' doesn't. Maybe it should be case insensitive? -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: setting tabular lines in multicolumn cells
Edwin Leuven wrote: > Michael Gerz wrote: >>> Edwin Leuven wrote: >>> >>> is there a reason to have both M_TOGGLE_LINE_TOP and TOGGLE_LINE_TOP ? >>> couldn't we just have one TOGGLE_LINE_TOP and set the proper flags >>> depending whether we are in a multicolumn cell or not? >> This is exactly what I proposed for 1.4 :-) > > the attach patch does just that... > > Georg Baum wrote: >>> what happened? >> >> Nobody dared to open the can of worms that the tabular inset is. IMO the >> tabular code that is spread over tabular.C and insets/insettabular.C >> needs to be put into one file and almost completely rewritten. Of course >> now is not the time to do so... > > agreed. the patch is an improvement to the current code though because > it basically gets rid of the M_TOGGLE_LINE stuff... I had a closer look, and IMHO it is only partly an improvement. You remove the functionality to set the borders of whole columns/rows. This is useful functionality that should not be removed. For example I could have a table with several columns, including multicolumn cells, where some have top lines and decide that I rather do not want any top row. I therefore want to be able to set or reset the top lines of a whole row. For toggling I agree: It does only make sense to toggle what is currently used, e.g. if at least one cell of a row has an individual top/bottom line setting that setting should be toggled. If the whole row has the same setting then the whole row should be toggled. The same applies of course to left/right lines and columns. > moreover, atm the dialog and toolbar give inconsistent results. the > patch solves that (and gets rid of a bog). Which one? I just committed apatch that renames the arguments of the tabular methods that you want to remove. These are useful IMO, even if they are currently not used by the dialog, so they should be kept. Maybe you now see what these arguments mean after I gave them meaningful names. If you rework your patch to not remove this functionality then it would be OK with me. It would be even better if it would be possible to set/reset whole column/row lines in the dialog, but since the dialog is horribly broken anwyway this can also wait. > the only thing left is the enabling/disabling of the toolbuttons (which > btw is not done atm either) > > it is not really clear to me in what situations we should allow what. i > found the following comment: > > // pay attention to left/right lines: they are only allowed > // to set if we are in first/last cell of row or if the left/right > // cell is also a multicolumn. > > why is that, and what would be the preferred policy here? This is the multicolumn case (normal cells are handled above that comment). It is not possible to set left/right lines inside of a multicolumn cell, they can of course only be set at the leftmost/rightmost cell of a multicolumn cell. This is one area where the code could be simplified (e.g. do not use dummy cells for multicolumn cells, but just one cell), but I believe that the current code is correct here. >>> what would be a good way of setting lines anyway? (am not a latex >>> expert) >>> >>> on a per cell basis using \cline and switching to \hline when all >>> columns are spanned? >> >> This is done AFAIK. > > not in the user interface What do you mean? You can set the lines in the UI per cell. If all lines in a row are set this results in a \hline, otherwise in one or more \cline. What else has \cline and \hline to do with the user interface? Georg
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
[EMAIL PROTECTED] wrote:
> * Create a toolbar button for this purpose by creating and icon with
> the name (?)
It would need to be called layout_Standard.xpm.
> "command-sequence layout Standard;"
> and place it in the directory ??. LyX will then execute the
> command when the user clicks on the icon.
> (Is this how you do it, I don't remember!)
No, only "layout Standard".
> * Do 'new-3', i.e. let 'layout' without argument set the paragraph layout
> to "Standard"
>
> * Create an (optional?) toolbar button for changing to "Standard"
Wrong!!!
Not "Standard", but the default layout of the text class. Not all classes
have a "Standard" layout, but all have a default layout.
The attached patch implements this. OK to go in? Before or after alpha? BTW
there was a "layout.xpm" icon in 1.3. What was its purpose? Should we use
it instead of my new one?
> PS. I discovered that the argument of the LFUN layout is case sensitive.
> In other words, 'layout Standard' works but 'layout standard' doesn't.
> Maybe it should be case insensitive?
Why? Are layout names case insensitive elsewhere?
GeorgIndex: src/text3.C
===
--- src/text3.C (Revision 15932)
+++ src/text3.C (Arbeitskopie)
@@ -809,24 +809,15 @@ void LyXText::dispatch(LCursor & cur, Fu
break;
case LFUN_LAYOUT: {
- lyxerr[Debug::INFO] << "LFUN_LAYOUT: (arg) "
- << to_utf8(cmd.argument()) << endl;
-
- // This is not the good solution to the empty argument
- // problem, but it will hopefully suffice for 1.2.0.
- // The correct solution would be to augument the
- // function list/array with information about what
- // functions needs arguments and their type.
- if (cmd.argument().empty()) {
- cur.errorMessage(_("LyX function 'layout' needs an argument."));
- break;
- }
+ string layout = to_ascii(cmd.argument());
+ lyxerr[Debug::INFO] << "LFUN_LAYOUT: (arg) " << layout << endl;
// Derive layout number from given argument (string)
// and current buffer's textclass (number)
LyXTextClass const & tclass = bv->buffer()->params().getLyXTextClass();
- bool hasLayout = tclass.hasLayout(to_utf8(cmd.argument()));
- string layout = to_utf8(cmd.argument());
+ if (layout.empty())
+ layout = tclass.defaultLayoutName();
+ bool hasLayout = tclass.hasLayout(layout);
// If the entry is obsolete, use the new one instead.
if (hasLayout) {
Index: lib/images/layout.xpm
===
--- lib/images/layout.xpm (Revision 0)
+++ lib/images/layout.xpm (Revision 0)
@@ -0,0 +1,25 @@
+/* XPM */
+static char * layout_xpm[] = {
+"20 20 2 1",
+" c None",
+". c #00",
+"",
+"",
+" . ",
+"",
+"",
+" . ",
+"",
+"",
+" . ",
+"",
+"",
+" . ",
+"",
+"",
+" . ",
+"",
+"",
+" . ",
+"",
+""};
Index: lib/ui/stdtoolbars.ui
===
--- lib/ui/stdtoolbars.ui (Revision 15932)
+++ lib/ui/stdtoolbars.ui (Arbeitskopie)
@@ -63,6 +63,7 @@ Toolbar "standard" "Standard"
End
Toolbar "extra" "Extra"
+ Item "Default" "layout"
Item "Numbered list" "layout Enumerate"
Item "Itemized list" "layout Itemize"
Item "List" "layout List"
lyx143: export to HTML and MS WORD (HTML)
Hi, if you do the above it looks like MS WORD (HTML) converts special characters to unicode (for example ä -> ), but the normal export to HTML does not. Which parameter of htlatex $$i 'html,word' 'symbol/!' '-cvalidate' is responsible for the conversion to unicode? And should not do the normal export to HTML this by default, too? Additionally: if export to html, delete the html-file and export again, LyX asks you if you want to overwrite the html-file, although it has already stored the new file. -- Viele Grüße, Hartmut Hungerhilfe: http://www.thehungersite.com Kampagne gegen den Ausverkauf der Deutschen Bahn: http://www.bahn-fuer-alle.de Das heutige Motto: Vergoldete Bücher machen aus faulen Studenten keine Doktoren.
Re: Easier return to Standard from Itemize, Enumerate, Description and List wanted
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> The attached patch implements this. OK to go in? I like it. >> PS. I discovered that the argument of the LFUN layout is case >> sensitive. In other words, 'layout Standard' works but 'layout >> standard' doesn't. Maybe it should be case insensitive? Georg> Why? Are layout names case insensitive elsewhere? No, I do not think so. JMarc
Re: setting tabular lines in multicolumn cells
Georg Baum wrote: I had a closer look, and IMHO it is only partly an improvement. You remove the functionality to set the borders of whole columns/rows. i think that it is possible to set borders of whole cols/rows. just select them and set/unset them. This is useful functionality that should not be removed. For example I could have a table with several columns, including multicolumn cells, where some have top lines and decide that I rather do not want any top row. I therefore want to be able to set or reset the top lines of a whole row. For toggling I agree: It does only make sense to toggle what is currently used, e.g. if at least one cell of a row has an individual top/bottom line setting that setting should be toggled. If the whole row has the same setting then the whole row should be toggled. The same applies of course to left/right lines and columns. afaics my changes make the dialog and toolbar act in a consistent way which i think is what people expect. If you rework your patch to not remove this functionality then it would be OK with me. It would be even better if it would be possible to set/reset whole column/row lines in the dialog, but since the dialog is horribly broken anwyway this can also wait. can you give me an example what you are missing? i didn't follow the one above. (i might be wrong but there is no table you cannot make after the patch that you could make before.) the only thing that is different with my patch is that when the cursor is in a multicolumn cell toggling applies to that cell's borders. it is not possible to toggle left/right (unless it is at the border of the table or if there is an adjacent multicolumn cell). to toggle left/right for the column either move to a non multicolumn cell or select the column. note that it behaves like the dialog. the unpatched toolbar otoh toggles the whole left/right colomn line setting (except the multi col ones) when in a multicol cell. more in general i think that it makes sense to have the toggling apply to what is selected: cursor in cell -> toggle cell selection -> toggle selection want to change the whole row/col? -> select row/col and toggle it is not really clear to me in what situations we should allow what. i found the following comment: // pay attention to left/right lines: they are only allowed // to set if we are in first/last cell of row or if the left/right // cell is also a multicolumn. why is that, and what would be the preferred policy here? This is the multicolumn case (normal cells are handled above that comment). It is not possible to set left/right lines inside of a multicolumn cell, they can of course only be set at the leftmost/rightmost cell of a multicolumn cell. the strange thing is that this comment is in the frontend whereas what you are saying should be handled by the core... What do you mean? You can set the lines in the UI per cell. If all lines in a row are set this results in a \hline, otherwise in one or more \cline. What else has \cline and \hline to do with the user interface? how do you do that? i don't manage to have a horizontal line that spans only a few columns unless i make the cell multicolumns cells... thanks, ed.
Re: Crash in view->something with Extended-Insets.lyx
On Tuesday 14 November 2006 8:46 pm, Georg Baum wrote: > > It was a lyx2lyx problem as I suspected, and I fixed it. José, if you have > a more elegant solution feel free to use that, but I wanted to make sure > that this is fixed as soon as possible. Sure, I was really amused when I saw your change. :-) nestdepth = nestdepth + 1 The right idiom is nestdepth += 1 and the same when you the nesting depth nestdepth -= 1 > Georg -- José Abílio
Re: Crash in view->something with Extended-Insets.lyx
Am Dienstag, 14. November 2006 21:46 schrieb Georg Baum: > It was a lyx2lyx problem as I suspected, and I fixed it. José, if you have > a more elegant solution feel free to use that, but I wanted to make sure > that this is fixed as soon as possible. Converted Extended-Insets.lyx looks now ok, but it still crashes here e.g. on export->latex Kornel -- Kornel Benko [EMAIL PROTECTED] pgpkwXhNMHA89.pgp Description: PGP signature
