Re: Question regarding Session management and toolbar state (ticket 7099)

On 03/01/2011 09:31, Vincent van Ravesteijn wrote: First, there are two different types of settings of toolbars: the location of the toolbars, and the visibility of the toolbars. The former is managed by Qt in QMainWindow::saveState()/restoreState(). The latter is done by LyX in

Re: Question regarding Session management and toolbar state (ticket 7099)

On 03/01/2011 09:43, Vincent van Ravesteijn wrote: What I forgot to say is: Why don't we implement saveState() and restoreState() in GuiToolbar which overrides QToolbar::saveState() and restoreState(). Then restoring the visibility of the toolbars is done by QMainWindow::restoreState. (At least,

Re: Question regarding Session management and toolbar state (ticket 7099)

On 01/03/2011 09:26 AM, Vincent van Ravesteijn wrote: Furthermore, I'm not sure yet what causes the bug, because it seems that if the user sets the toolbar visibility from within LyX, this setting is lost again on the new start-up of LyX. Why are the settings not stored properly when exiting LyX

Re: Question regarding Session management and toolbar state (ticket 7099)

On 01/03/2011 02:03 PM, Vincent van Ravesteijn wrote: Furthermore, I'm not sure yet what causes the bug, because it seems that if the user sets the toolbar visibility from within LyX, this setting is lost again on the new start-up of LyX. Why are the settings not stored properly when exiting LyX

Re: r36976 - lyx-devel/trunk/src/insets

On 12/21/2010 09:38 AM, Jean-Marc Lasgouttes wrote: Le 21/12/2010 00:02, Richard Heck a écrit : I guess the idea was that greyed out notes get the same status for instance as deleted text when change tracking is on. In that case, you don't want the counters to be treated as part of the

Re: warns

On 12/20/2010 02:00 PM, Pavel Sanda wrote: Abdelrazak Younes wrote: I don't think this could happen but yes, better safe than sorry :-) dunno how much is this related to the last changes but is see new assert in bugzilla with lyx::RandomAccessListlyx::Paragraph::operator[] keyword

Re: r36976 - lyx-devel/trunk/src/insets

On 12/21/2010 09:38 AM, Jean-Marc Lasgouttes wrote: Le 21/12/2010 00:02, Richard Heck a écrit : I guess the idea was that greyed out notes get the same status for instance as deleted text when change tracking is on. In that case, you don't want the counters to be treated as part of the

Re: warns

On 12/20/2010 02:00 PM, Pavel Sanda wrote: Abdelrazak Younes wrote: I don't think this could happen but yes, better safe than sorry :-) dunno how much is this related to the last changes but is see new assert in bugzilla with lyx::RandomAccessList::operator[] keyword... #7188

Re: std::distance and RandomAccessList

On 18/12/2010 22:03, Bernhard Roider wrote: 2010/12/18 Abdelrazak Younes you...@lyx.org mailto:you...@lyx.org On 18/12/2010 19:33, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 19:08, Abdelrazak Younes a écrit : On 18/12/2010 18:57, Jean-Marc Lasgouttes wrote

Re: [RFC] and [patch] - support to define header /footer lines

On 16/12/2010 12:02, Helge Hafting wrote: On 15. des. 2010 14:50, Richard Heck wrote: On 12/15/2010 08:43 AM, Helge Hafting wrote: How about defining custom Insets instead of styles? This would put the new objects in a less prominent place (i.e. not interfering with the normal styles), clearly

Re: [PATCH] New Toolbar Settings Dialog

I created a new branch for that in git: http://gitorious.org/lyx/lyx/commits/toolbar-settings Abdel. On 15/12/2010 00:20, Abdelrazak Younes wrote: Hello, This is an old promise of mines. This an attempt to get rid of the menubased toolbar-switching and the tristate toggling. The patch

Re: warns

On 12/20/2010 02:37 AM, Richard Heck wrote: On 12/19/2010 05:00 PM, Pavel Sanda wrote: CXXoutput_xhtml.o output_latex.cpp: In function 'void lyx::TeXOnePar(const lyx::Buffer, const lyx::Text, lyx::pit_type, lyx::odocstream, lyx::TexRow, const lyx::OutputParams, const std::string,

Re: std::distance and RandomAccessList

On 18/12/2010 22:03, Bernhard Roider wrote: 2010/12/18 Abdelrazak Younes <you...@lyx.org <mailto:you...@lyx.org>> On 18/12/2010 19:33, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 19:08, Abdelrazak Younes a écrit : On 18/12/2010 18:57, Jean-Marc Lasg

Re: [RFC] and [patch] - support to define header /footer lines

On 16/12/2010 12:02, Helge Hafting wrote: On 15. des. 2010 14:50, Richard Heck wrote: On 12/15/2010 08:43 AM, Helge Hafting wrote: How about defining custom Insets instead of styles? This would put the new objects in a less prominent place (i.e. not interfering with the "normal" styles),

Re: [PATCH] New Toolbar Settings Dialog

I created a new branch for that in git: http://gitorious.org/lyx/lyx/commits/toolbar-settings Abdel. On 15/12/2010 00:20, Abdelrazak Younes wrote: Hello, This is an old promise of mines. This an attempt to get rid of the menubased toolbar-switching and the tristate toggling. The patch

Re: warns

On 12/20/2010 02:37 AM, Richard Heck wrote: On 12/19/2010 05:00 PM, Pavel Sanda wrote: CXXoutput_xhtml.o output_latex.cpp: In function 'void lyx::TeXOnePar(const lyx::Buffer&, const lyx::Text&, lyx::pit_type, lyx::odocstream&, lyx::TexRow&, const lyx::OutputParams&, const

Re: std::distance and RandomAccessList

On 18/12/2010 17:37, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 09:22, Abdelrazak Younes a écrit : OK, I just committed a fix then. Please try it. On a release build on trunk, for exporting to pdflatex format I get before: 220 seconds after: 21 seconds No diff between the two files

Re: std::distance and RandomAccessList

On 18/12/2010 18:57, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 17:41, Abdelrazak Younes a écrit : What part of that could possibly go to branch? I guess introducing RandomListAccess::position() and using it will be enough. Why does this remove the quadratic behaviour? distance(it1, it2

Re: std::distance and RandomAccessList

On 18/12/2010 19:33, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 19:08, Abdelrazak Younes a écrit : On 18/12/2010 18:57, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 17:41, Abdelrazak Younes a écrit : What part of that could possibly go to branch? I guess introducing RandomListAccess

Re: LyX on gitorious

OK, within msysgit that gives: $ git clone g...@gitorious.org:lyx/lyx.git $ cd lyx $ git svn init svn://svn.lyx.org/lyx/lyx-devel/ -T trunk -b branches -t tags Using higher level of URL: svn://svn.lyx.org/lyx/lyx-devel = svn://svn.lyx.org/lyx $ cp .git/refs/heads/master

Re: std::distance and RandomAccessList

On 18/12/2010 17:37, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 09:22, Abdelrazak Younes a écrit : OK, I just committed a fix then. Please try it. On a release build on trunk, for exporting to pdflatex format I get before: 220 seconds after: 21 seconds No diff between the two files

Re: std::distance and RandomAccessList

On 18/12/2010 18:57, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 17:41, Abdelrazak Younes a écrit : What part of that could possibly go to branch? I guess introducing RandomListAccess::position() and using it will be enough. Why does this remove the quadratic behaviour? distance(it1, it2

Re: std::distance and RandomAccessList

On 18/12/2010 19:33, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 19:08, Abdelrazak Younes a écrit : On 18/12/2010 18:57, Jean-Marc Lasgouttes wrote: Le 18 déc. 2010 à 17:41, Abdelrazak Younes a écrit : What part of that could possibly go to branch? I guess introducing RandomListAccess

Re: LyX on gitorious

OK, within msysgit that gives: $ git clone g...@gitorious.org:lyx/lyx.git $ cd lyx $ git svn init svn://svn.lyx.org/lyx/lyx-devel/ -T trunk -b branches -t tags Using higher level of URL: svn://svn.lyx.org/lyx/lyx-devel => svn://svn.lyx.org/lyx $ cp .git/refs/heads/master

Re: Proposal for LyX performance problems when outliner is opened

On 12/17/2010 03:33 AM, Richard Heck wrote: On 12/16/10 9:11 PM, Pavel Sanda wrote: unless there are some objections i will commit it. once in we'll see whether the new behaviour does not irritate the second half of people which has no performance problems... I have another patch in the

Re: Proposal for LyX performance problems when outliner is opened

On 12/17/2010 01:05 PM, Vincent van Ravesteijn wrote: On Thu, Dec 16, 2010 at 3:43 AM, Pavel Sandasa...@lyx.org wrote: hi, the attached patch has profound impact on the speed of moving with cursor and typing as well. at least here. if you wonder how to reproduce the slowness problems on

Re: Proposal for LyX performance problems when outliner is opened

On 12/17/2010 04:19 PM, Pavel Sanda wrote: Vincent van Ravesteijn wrote: I think we shouldn't fall back into this kind of hack before we know i can offer some rc variable or small slider for the delay in outliner. if its not acceptable either, well, its another local patch again :)

Re: std::distance and RandomAccessList

On 12/17/2010 04:50 PM, Jean-Marc Lasgouttes wrote: Le 16/12/2010 21:46, Abdelrazak Younes a écrit : On 15/12/2010 18:17, Jean-Marc Lasgouttes wrote: Le 15/12/2010 17:54, Michael Joyner a écrit : One of our initial goals was to try and maintain an easy to edit file format should the internal

Re: std::distance and RandomAccessList

On 12/17/2010 05:41 PM, Jean-Marc Lasgouttes wrote: Le 17/12/2010 17:17, Abdelrazak Younes a écrit : Anyway, I tested this change and the UserGuide exports correctly (and identically of course). But the bad news is that it make no difference in speed. So my conclusion is that the speed issue

Re: Proposal for LyX performance problems when outliner is opened

On 12/17/2010 05:42 PM, Pavel Sanda wrote: Pavel Sanda wrote: +// Enable if you dont want the delaying business, cf #7138. +#ifdef 0 + updateViewForce(); + return; +#endif erm #if 0 of course... make it an #ifndef DELAY_UPDATE_VIEW and I'd be happy. Abdel. pavel

Re: Proposal for LyX performance problems when outliner is opened

On 17/12/2010 18:18, Pavel Sanda wrote: Abdelrazak Younes wrote: erm #if 0 of course... make it an #ifndef DELAY_UPDATE_VIEW and I'd be happy. this means the bug remains effectively unfixed for all other users. No, you can of course set that to 1 by default of course (like

Re: Proposal for LyX performance problems when outliner is opened

On 12/17/2010 03:33 AM, Richard Heck wrote: On 12/16/10 9:11 PM, Pavel Sanda wrote: unless there are some objections i will commit it. once in we'll see whether the new behaviour does not irritate the second half of people which has no performance problems... I have another patch in the

Re: Proposal for LyX performance problems when outliner is opened

On 12/17/2010 01:05 PM, Vincent van Ravesteijn wrote: On Thu, Dec 16, 2010 at 3:43 AM, Pavel Sanda wrote: hi, the attached patch has profound impact on the speed of moving with cursor and typing as well. at least here. if you wonder how to reproduce the slowness problems

Re: Proposal for LyX performance problems when outliner is opened

On 12/17/2010 04:19 PM, Pavel Sanda wrote: Vincent van Ravesteijn wrote: I think we shouldn't fall back into this kind of hack before we know i can offer some rc variable or small slider for the delay in outliner. if its not acceptable either, well, its another local patch again :)

Re: std::distance and RandomAccessList

On 12/17/2010 04:50 PM, Jean-Marc Lasgouttes wrote: Le 16/12/2010 21:46, Abdelrazak Younes a écrit : On 15/12/2010 18:17, Jean-Marc Lasgouttes wrote: Le 15/12/2010 17:54, Michael Joyner a écrit : One of our initial goals was to try and maintain an easy to edit file format should the internal

Re: std::distance and RandomAccessList

On 12/17/2010 05:41 PM, Jean-Marc Lasgouttes wrote: Le 17/12/2010 17:17, Abdelrazak Younes a écrit : Anyway, I tested this change and the UserGuide exports correctly (and identically of course). But the bad news is that it make no difference in speed. So my conclusion is that the speed issue

Re: Proposal for LyX performance problems when outliner is opened

On 12/17/2010 05:42 PM, Pavel Sanda wrote: Pavel Sanda wrote: +// Enable if you dont want the delaying business, cf #7138. +#ifdef 0 + updateViewForce(); + return; +#endif erm "#if 0" of course... make it an #ifndef DELAY_UPDATE_VIEW and I'd be happy. Abdel.

Re: Proposal for LyX performance problems when outliner is opened

On 17/12/2010 18:18, Pavel Sanda wrote: Abdelrazak Younes wrote: erm "#if 0" of course... make it an #ifndef DELAY_UPDATE_VIEW and I'd be happy. this means the bug remains effectively unfixed for all other users. No, you can of course set that to 1 by default of co

Re: Proposal for LyX performance problems when outliner is opened

On 12/16/2010 03:43 AM, Pavel Sanda wrote: hi, the attached patch has profound impact on the speed of moving with cursor and typing as well. at least here. if you wonder how to reproduce the slowness problems on your box, try to open user guide, set the nesting on deepest level and try to type

Re: Fix compiler warnings in pedantic mode

On 12/16/2010 07:25 AM, Stephan Witt wrote: Am 16.12.2010 um 00:44 schrieb Pavel Sanda: Stephan Witt wrote: Index: src/frontends/Clipboard.h === --- src/frontends/Clipboard.h (Revision 36891) +++

Re: std::distance and RandomAccessList

On 15/12/2010 18:17, Jean-Marc Lasgouttes wrote: Le 15/12/2010 17:54, Michael Joyner a écrit : One of our initial goals was to try and maintain an easy to edit file format should the internal customers need to tweak any of the outputs. The ones who would be doing the editing are less than

Re: Proposal for LyX performance problems when outliner is opened

On 12/16/2010 03:43 AM, Pavel Sanda wrote: hi, the attached patch has profound impact on the speed of moving with cursor and typing as well. at least here. if you wonder how to reproduce the slowness problems on your box, try to open user guide, set the nesting on deepest level and try to type

Re: Fix compiler warnings in pedantic mode

On 12/16/2010 07:25 AM, Stephan Witt wrote: Am 16.12.2010 um 00:44 schrieb Pavel Sanda: Stephan Witt wrote: Index: src/frontends/Clipboard.h === --- src/frontends/Clipboard.h (Revision 36891) +++

Re: std::distance and RandomAccessList

On 15/12/2010 18:17, Jean-Marc Lasgouttes wrote: Le 15/12/2010 17:54, Michael Joyner a écrit : One of our initial goals was to try and maintain an easy to edit file format should the internal customers need to "tweak" any of the outputs. The ones who would be doing the editing are less than

LyX on gitorious

Hi Vincent, I would like to create a new branch there for my toolbar-settings patch but the repo is not up to date. As I am not familiar with git svn could you please send your recipe to rebase git master from svn trunk? Thanks in advance, Abdel.

Re: std::distance and RandomAccessList

On 15/12/2010 18:51, Abdelrazak Younes wrote: On 15/12/2010 18:17, Jean-Marc Lasgouttes wrote: Le 15/12/2010 17:54, Michael Joyner a écrit : One of our initial goals was to try and maintain an easy to edit file format should the internal customers need to tweak any of the outputs. The ones

Re: std::distance and RandomAccessList

On 15/12/2010 18:17, Jean-Marc Lasgouttes wrote: Le 15/12/2010 17:54, Michael Joyner a écrit : One of our initial goals was to try and maintain an easy to edit file format should the internal customers need to tweak any of the outputs. The ones who would be doing the editing are less than

Re: LyX on gitorious

On 15/12/2010 18:57, Vincent van Ravesteijn wrote: On Wed, Dec 15, 2010 at 4:53 PM, Abdelrazak Younesyou...@lyx.org wrote: Hi Vincent, I would like to create a new branch there for my toolbar-settings patch but the repo is not up to date. As I am not familiar with git svn could you please

Re: r36895 - lyx-devel/trunk/src

On 15/12/2010 23:02, Vincent van Ravesteijn wrote: On Wed, Dec 15, 2010 at 10:48 PM,you...@lyx.org wrote: Author: younes Date: Wed Dec 15 22:48:00 2010 New Revision: 36895 URL: http://www.lyx.org/trac/changeset/36895 Log: get rid of TeXDeeper: this was hiding the recursiveness of

Re: std::distance and RandomAccessList

On 15/12/2010 23:12, Jean-Marc Lasgouttes wrote: Le 15/12/2010 18:51, Abdelrazak Younes a écrit : It seems correct. At the time I remember saying to myself that using std::distance was not optimal and that we should use some new fast method in RandomAccessList but I did not bother because

Re: r36896 - lyx-devel/trunk/src

On 16/12/2010 00:39, you...@lyx.org wrote: Author: younes Date: Thu Dec 16 00:39:38 2010 New Revision: 36896 URL: http://www.lyx.org/trac/changeset/36896 Log: Split TeXEnvironment() in three functions. The real optimisation is yet to come. Pavel, I should have probably requested your approval

LyX on gitorious

Hi Vincent, I would like to create a new branch there for my toolbar-settings patch but the repo is not up to date. As I am not familiar with git svn could you please send your recipe to rebase git master from svn trunk? Thanks in advance, Abdel.

Re: std::distance and RandomAccessList

On 15/12/2010 18:51, Abdelrazak Younes wrote: On 15/12/2010 18:17, Jean-Marc Lasgouttes wrote: Le 15/12/2010 17:54, Michael Joyner a écrit : One of our initial goals was to try and maintain an easy to edit file format should the internal customers need to "tweak" any of th

Re: std::distance and RandomAccessList

On 15/12/2010 18:17, Jean-Marc Lasgouttes wrote: Le 15/12/2010 17:54, Michael Joyner a écrit : One of our initial goals was to try and maintain an easy to edit file format should the internal customers need to "tweak" any of the outputs. The ones who would be doing the editing are less than

Re: LyX on gitorious

On 15/12/2010 18:57, Vincent van Ravesteijn wrote: On Wed, Dec 15, 2010 at 4:53 PM, Abdelrazak Younes<you...@lyx.org> wrote: Hi Vincent, I would like to create a new branch there for my toolbar-settings patch but the repo is not up to date. As I am not familiar with git svn could you

Re: r36895 - lyx-devel/trunk/src

On 15/12/2010 23:02, Vincent van Ravesteijn wrote: On Wed, Dec 15, 2010 at 10:48 PM, wrote: Author: younes Date: Wed Dec 15 22:48:00 2010 New Revision: 36895 URL: http://www.lyx.org/trac/changeset/36895 Log: get rid of TeXDeeper: this was hiding the recursiveness of

Re: std::distance and RandomAccessList

On 15/12/2010 23:12, Jean-Marc Lasgouttes wrote: Le 15/12/2010 18:51, Abdelrazak Younes a écrit : It seems correct. At the time I remember saying to myself that using std::distance was not optimal and that we should use some new fast method in RandomAccessList but I did not bother because

Re: r36896 - lyx-devel/trunk/src

On 16/12/2010 00:39, you...@lyx.org wrote: Author: younes Date: Thu Dec 16 00:39:38 2010 New Revision: 36896 URL: http://www.lyx.org/trac/changeset/36896 Log: Split TeXEnvironment() in three functions. The real optimisation is yet to come. Pavel, I should have probably requested your approval

Re: [RFC] and [patch] - support to define header /footer lines

On 13/12/2010 22:04, Guenter Milde wrote: On 2010-12-13, Helge Hafting wrote: On 13. des. 2010 13:16, Helge Hafting wrote: On 23. sep. 2010 03:50, Uwe Stöhr wrote: The only disadvantage being that the module will now add 18 new paragraph types instead of 6 (or 12).

Re: [RFC] and [patch] - support to define header /footer lines

On 14/12/2010 12:09, Abdelrazak Younes wrote: On 13/12/2010 22:04, Guenter Milde wrote: On 2010-12-13, Helge Hafting wrote: On 13. des. 2010 13:16, Helge Hafting wrote: On 23. sep. 2010 03:50, Uwe Stöhr wrote: The only disadvantage being that the module will now add 18 new paragraph types

Modules and required document settings (ex: for header and footer module)

Hi Richard, Would it be possible to add a new item in the layout syntax to require a specific document settings? Something like: RequiredSettingsetting:value In the case of the header and footer module that would give the attached. The goal is of course to automatically set the setting

Re: r36884 - in lyx-devel/trunk: lib/layouts src/insets

On 15/12/2010 00:16, rgh...@lyx.org wrote: Author: rgheck Date: Wed Dec 15 00:16:19 2010 New Revision: 36884 URL: http://www.lyx.org/trac/changeset/36884 Log: Allow customization of label string for note insets. We actually had strings in the layout file, but they were not used. Question:

Re: Modules and required document settings (ex: for header and footer module)

On 14/12/2010 15:42, Richard Heck wrote: On 12/14/2010 06:56 AM, Abdelrazak Younes wrote: Hi Richard, Would it be possible to add a new item in the layout syntax to require a specific document settings? Something like: RequiredSettingsetting:value In the case of the header and footer

Re: [RFC] and [patch] - support to define header /footer lines

On 13/12/2010 22:04, Guenter Milde wrote: On 2010-12-13, Helge Hafting wrote: On 13. des. 2010 13:16, Helge Hafting wrote: On 23. sep. 2010 03:50, Uwe Stöhr wrote: The only disadvantage being that the module will now add 18 new paragraph types instead of 6 (or 12).

Re: [RFC] and [patch] - support to define header /footer lines

On 14/12/2010 12:09, Abdelrazak Younes wrote: On 13/12/2010 22:04, Guenter Milde wrote: On 2010-12-13, Helge Hafting wrote: On 13. des. 2010 13:16, Helge Hafting wrote: On 23. sep. 2010 03:50, Uwe Stöhr wrote: The only disadvantage being that the module will now add 18 new paragraph types

Modules and required document settings (ex: for header and footer module)

Hi Richard, Would it be possible to add a new item in the layout syntax to require a specific document settings? Something like: RequiredSettingsetting:value In the case of the header and footer module that would give the attached. The goal is of course to automatically set the setting

Re: r36884 - in lyx-devel/trunk: lib/layouts src/insets

On 15/12/2010 00:16, rgh...@lyx.org wrote: Author: rgheck Date: Wed Dec 15 00:16:19 2010 New Revision: 36884 URL: http://www.lyx.org/trac/changeset/36884 Log: Allow customization of label string for note insets. We actually had strings in the layout file, but they were not used. Question:

Re: Modules and required document settings (ex: for header and footer module)

On 14/12/2010 15:42, Richard Heck wrote: On 12/14/2010 06:56 AM, Abdelrazak Younes wrote: Hi Richard, Would it be possible to add a new item in the layout syntax to require a specific document settings? Something like: RequiredSettingsetting:value In the case of the header and footer

Re: r36771 - lyx-devel/trunk/src

On 12/08/2010 02:45 PM, Vincent van Ravesteijn wrote: While you're at this, I wonder if you have a relatively easy fix for this bug. Add a character to a document, then go to the end of the document. Now do Undo, Redo. The redo moves you to the end of the document, so you don't actually see what

Re: [PATCH] external inset supporting spreadsheet import into LyX 2.0

On 12/08/2010 05:11 PM, Helge Hafting wrote: This patch lets LyX 2.0 use spreadsheets as external insets: * gnumeric spreadsheets * openoffice spreadsheets * excel spreadhsheets This is done using the ssconvert utility that comes with gnumeric, so it is necessary to have gnumeric even if the

Re: r36771 - lyx-devel/trunk/src

On 12/09/2010 09:30 AM, Jean-Marc Lasgouttes wrote: Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how

Re: r36771 - lyx-devel/trunk/src

On 12/09/2010 10:52 AM, Abdelrazak Younes wrote: On 12/09/2010 09:30 AM, Jean-Marc Lasgouttes wrote: Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how

Re: r36771 - lyx-devel/trunk/src

On 12/08/2010 02:45 PM, Vincent van Ravesteijn wrote: While you're at this, I wonder if you have a relatively easy fix for this bug. Add a character to a document, then go to the end of the document. Now do Undo, Redo. The redo moves you to the end of the document, so you don't actually see what

Re: [PATCH] external inset supporting spreadsheet import into LyX 2.0

On 12/08/2010 05:11 PM, Helge Hafting wrote: This patch lets LyX 2.0 use spreadsheets as external insets: * gnumeric spreadsheets * openoffice spreadsheets * excel spreadhsheets This is done using the "ssconvert" utility that comes with gnumeric, so it is necessary to have gnumeric even if the

Re: r36771 - lyx-devel/trunk/src

On 12/09/2010 09:30 AM, Jean-Marc Lasgouttes wrote: Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how

Re: r36771 - lyx-devel/trunk/src

On 12/09/2010 10:52 AM, Abdelrazak Younes wrote: On 12/09/2010 09:30 AM, Jean-Marc Lasgouttes wrote: Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how

Re: Question about InsetParamsDialog::checkWidget (abdel?)

On 12/06/2010 12:39 PM, Jean-Marc Lasgouttes wrote: In the aforementioned function, I read: bool const lfun_ok = lyx::getStatus(FuncRequest(code, argument)).enabled(); bool const read_only = buffer().isReadonly(); okPB-setEnabled(!synchronized_view widget_ok !read_only

Re: Question about InsetParamsDialog::checkWidget (abdel?)

On 12/06/2010 12:39 PM, Jean-Marc Lasgouttes wrote: In the aforementioned function, I read: bool const lfun_ok = lyx::getStatus(FuncRequest(code, argument)).enabled(); bool const read_only = buffer().isReadonly(); okPB->setEnabled(!synchronized_view && widget_ok && !read_only &&

Inverting the dispatch execution order

Hi, I would like to invert the dispatch execution order, i.e.: Cursor - Buffer - BufferView - GuiView - GuiApplication The current top-down order was always weird to me because when you type the first thing to try is to execute at the cursor location, not at the global application level.

Re: Inverting the dispatch execution order

On 12/05/2010 11:39 PM, Pavel Sanda wrote: Abdelrazak Younes wrote: Any reason why not doing so? yes sir :) because it can introduce new regressions? Valid one. because you have generally almost no time to fix them when they appear? Not fair. I am not able

Re: r36734 - in lyx-devel/trunk/src: . frontends/qt4

On 12/05/2010 08:59 PM, Richard Heck wrote: On 12/04/2010 08:18 PM, you...@lyx.org wrote: Author: younes Date: Sun Dec 5 02:18:32 2010 New Revision: 36734 URL: http://www.lyx.org/trac/changeset/36734 Log: Move buffer dispatching code from GuiView::dispatchToBufferView() to

Re: r36710 - in lyx-devel/trunk/src: . insets

On 12/05/2010 08:53 PM, Richard Heck wrote: On 12/04/2010 06:36 PM, Abdelrazak Younes wrote: On 04/12/2010 23:55, Richard Heck wrote: On 12/04/2010 03:41 PM, Abdelrazak Younes wrote: On 04/12/2010 04:15, rgh...@lyx.org wrote: Author: rgheck Date: Sat Dec 4 04:15:53 2010 New Revision: 36710

Inverting the dispatch execution order

Hi, I would like to invert the dispatch execution order, i.e.: Cursor -> Buffer -> BufferView -> GuiView -> GuiApplication The current top-down order was always weird to me because when you type the first thing to try is to execute at the cursor location, not at the global application level.

Re: Inverting the dispatch execution order

On 12/05/2010 11:39 PM, Pavel Sanda wrote: Abdelrazak Younes wrote: Any reason why not doing so? yes sir :) because it can introduce new regressions? Valid one. because you have generally almost no time to fix them when they appear? Not fair. I am not able

Re: r36734 - in lyx-devel/trunk/src: . frontends/qt4

On 12/05/2010 08:59 PM, Richard Heck wrote: On 12/04/2010 08:18 PM, you...@lyx.org wrote: Author: younes Date: Sun Dec 5 02:18:32 2010 New Revision: 36734 URL: http://www.lyx.org/trac/changeset/36734 Log: Move buffer dispatching code from GuiView::dispatchToBufferView() to

Re: r36710 - in lyx-devel/trunk/src: . insets

On 12/05/2010 08:53 PM, Richard Heck wrote: On 12/04/2010 06:36 PM, Abdelrazak Younes wrote: On 04/12/2010 23:55, Richard Heck wrote: On 12/04/2010 03:41 PM, Abdelrazak Younes wrote: On 04/12/2010 04:15, rgh...@lyx.org wrote: Author: rgheck Date: Sat Dec 4 04:15:53 2010 New Revision: 36710

Re: r36710 - in lyx-devel/trunk/src: . insets

On 04/12/2010 04:15, rgh...@lyx.org wrote: Author: rgheck Date: Sat Dec 4 04:15:53 2010 New Revision: 36710 URL: http://www.lyx.org/trac/changeset/36710 Log: Revert r36696: We can't collect BibTeX information during the updateBuffer() traversal. The reason is simple: InsetCitation needs access

Re: r36721 - lyx-devel/trunk/src/frontends/qt4

On 04/12/2010 23:28, Pavel Sanda wrote: you...@lyx.org wrote: Author: younes Date: Sat Dec 4 23:07:39 2010 New Revision: 36721 URL: http://www.lyx.org/trac/changeset/36721 Log: Make sure the current view is set to busy in order to avoid a crash due to a screen redraw in the middle of a

Re: r36710 - in lyx-devel/trunk/src: . insets

On 04/12/2010 23:55, Richard Heck wrote: On 12/04/2010 03:41 PM, Abdelrazak Younes wrote: On 04/12/2010 04:15, rgh...@lyx.org wrote: Author: rgheck Date: Sat Dec 4 04:15:53 2010 New Revision: 36710 URL: http://www.lyx.org/trac/changeset/36710 Log: Revert r36696: We can't collect BibTeX

Re: r36731 - lyx-devel/trunk/src

On 05/12/2010 00:21, you...@lyx.org wrote: Author: younes Date: Sun Dec 5 00:21:47 2010 New Revision: 36731 URL: http://www.lyx.org/trac/changeset/36731 Log: Fix bug #7071 in cutSelection: After a cut operation, we need to make sure that the Buffer is updated because some further operation

Re: r36710 - in lyx-devel/trunk/src: . insets

On 04/12/2010 04:15, rgh...@lyx.org wrote: Author: rgheck Date: Sat Dec 4 04:15:53 2010 New Revision: 36710 URL: http://www.lyx.org/trac/changeset/36710 Log: Revert r36696: We can't collect BibTeX information during the updateBuffer() traversal. The reason is simple: InsetCitation needs access

Re: r36721 - lyx-devel/trunk/src/frontends/qt4

On 04/12/2010 23:28, Pavel Sanda wrote: you...@lyx.org wrote: Author: younes Date: Sat Dec 4 23:07:39 2010 New Revision: 36721 URL: http://www.lyx.org/trac/changeset/36721 Log: Make sure the current view is set to busy in order to avoid a crash due to a screen redraw in the middle of a

Re: r36710 - in lyx-devel/trunk/src: . insets

On 04/12/2010 23:55, Richard Heck wrote: On 12/04/2010 03:41 PM, Abdelrazak Younes wrote: On 04/12/2010 04:15, rgh...@lyx.org wrote: Author: rgheck Date: Sat Dec 4 04:15:53 2010 New Revision: 36710 URL: http://www.lyx.org/trac/changeset/36710 Log: Revert r36696: We can't collect BibTeX

Re: r36731 - lyx-devel/trunk/src

On 05/12/2010 00:21, you...@lyx.org wrote: Author: younes Date: Sun Dec 5 00:21:47 2010 New Revision: 36731 URL: http://www.lyx.org/trac/changeset/36731 Log: Fix bug #7071 in cutSelection: After a cut operation, we need to make sure that the Buffer is updated because some further operation

Re: Suggestion - preamble inset

On 02/12/2010 22:45, Richard Heck wrote: On 12/01/2010 07:45 AM, Abdelrazak Younes wrote: Why not simply add a preamble editor in the branches dialog? LyX will then collect the preamble for each branches. I guess this would be a format change but it strikes me as the correct solution

Re: LyX 2.0 - some bugs

On 30/11/2010 17:33, Pavel Sanda wrote: Liviu Andronic wrote: I would suspect that a wavy line might be more desirable (as in MS Word, gtkspell, OOo, etc.), and if I remember this was the original implementation (although then the wavy line was too big :) ). so we are at circles,

Re: r36662 - lyx-devel/trunk/src/frontends/qt4

On 03/12/2010 15:18, Jürgen Spitzmüller wrote: Pavel Sanda wrote: you seriously mean that there is arabic translation for eg hunspell? Maybe no translation, but a transliteration (i.e., use of arabic script). there was some point in having aspell (libary) as a translatable

Re: LyX 2.0 - some bugs

On 03/12/2010 15:52, Stephan Witt wrote: Am 03.12.2010 um 15:31 schrieb Abdelrazak Younes: On 30/11/2010 17:33, Pavel Sanda wrote: Liviu Andronic wrote: I would suspect that a wavy line might be more desirable (as in MS Word, gtkspell, OOo, etc.), and if I remember

Re: LyX 2.0 - some bugs

On 03/12/2010 15:58, Vincent van Ravesteijn wrote: Op 3-12-2010 15:54, Abdelrazak Younes schreef: On 03/12/2010 15:52, Stephan Witt wrote: Am 03.12.2010 um 15:31 schrieb Abdelrazak Younes: On 30/11/2010 17:33, Pavel Sanda wrote: Liviu Andronic wrote: I would suspect that a wavy line

Re: LyX 2.0 - some bugs

On 03/12/2010 16:18, Pavel Sanda wrote: Stephan Witt wrote: I did no serious investigation until now... Only one example: I tried to adjust the left margin to zoom factor. Guess what happened... The cursor was misplaced badly. and soon you'll get another ones ... few times i tried to

<    3   4   5   6   7   8   9   10   11   12   >