Jean-Marc Lasgouttes wrote:
Been a while? ;-)
The deleted_ part has been added by Bo :-p
That's what I thought---it seemed to fit into that scheme---though svn
blame tagged you or Andre, probably just for moving some things around.
rh
Been a while? ;-)
The deleted_ part has been added by Bo :-p
JMarc
Jean-Marc Lasgouttes wrote:
The attached fixes it for me. Anyone have any thoughts about this?
It looks reasonable, but I do not know this code very well.
OK, thanks.
// -*- C++ -*-
/**
* \file KeySequence.h
* This file is part of LyX, the document processor.
* Licence details can be found i
The attached fixes it for me. Anyone have any thoughts about this?
It looks reasonable, but I do not know this code very well.
JMarc
Jason Walker wrote:
Dear LyX developers,
In LyX 1.6.3 svn (my build is not completely up-to -date though), LyX crashes
if you do the following:
1) Tools->Preferences->Editing->Shortcut.
2) Choose an action *with* a shortcut. Press "Modify". Click "Delete Key" until you
clear the shortcut compl
On Tue, Apr 29, 2008 at 04:58:14PM +0200, Andre Poenitz wrote:
> On Tue, Apr 29, 2008 at 04:35:00PM +0200, Enrico Forestieri wrote:
> > On both mingw and cygwin, LyX crashes on exit. This is due to a doubly
> > destroyed object and I wonder why others don't see this with MSVC.
>
> I fail to see th
Same for Mac with the Mac pasteboard.
Stefan
Am 29.04.2008 um 16:58 schrieb Andre Poenitz:
On Tue, Apr 29, 2008 at 04:35:00PM +0200, Enrico Forestieri wrote:
On both mingw and cygwin, LyX crashes on exit. This is due to a
doubly
destroyed object and I wonder why others don't see this with M
On Tue, Apr 29, 2008 at 04:35:00PM +0200, Enrico Forestieri wrote:
> On both mingw and cygwin, LyX crashes on exit. This is due to a doubly
> destroyed object and I wonder why others don't see this with MSVC.
I fail to see the double deletion.
> ===
On both mingw and cygwin, LyX crashes on exit. This is due to a doubly
destroyed object and I wonder why others don't see this with MSVC.
This is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0096e06a in QWindowsMimeList::init ()
(gdb) bt
#0 0x0096e06a in QWindowsMimeList
Richard Heck <[EMAIL PROTECTED]> writes:
> lyx --export text file.lyx crashed with a segfault in hideDialogs().
> The patch fixeth the crash. OK?
Yes.
JMarc
lyx --export text file.lyx crashed with a segfault in hideDialogs(). The
patch fixeth the crash. OK?
I'm not sure why this was happening only with text and not (say) with
PDF. So maybe there is a more fundamental issue somewhere.
Richard
--
=
I tested this and it works fine. So OK by me.
rgards Uwe
Stefan Schimanski wrote:
> The bug: http://bugzilla.lyx.org/show_bug.cgi?id=3875
>
> The problem: On fullscreen redraw the metrics of all visible
> paragraphs are recreated and stored in the TextMetrics object. If the
> number of paragraphs on screen does not change everything is fine
> because t
The bug: http://bugzilla.lyx.org/show_bug.cgi?id=3875
The problem: On fullscreen redraw the metrics of all visible
paragraphs are recreated and stored in the TextMetrics object. If the
number of paragraphs on screen does not change everything is fine
because the paragraph metrics cache is j
We're redrawing the whole thing, too? Is *that* necessary after
every backspace?!
Everything = the paragraph. That are the rules of the games
currently. I and others have ideas to speed up the drawing
considerable for 1.6.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Dov Feldstern wrote:
Stefan Schimanski wrote:
Am 31.05.2007 um 22:27 schrieb Stefan Schimanski:
The patch:
Index: src/Text.cpp
===
--- src/Text.cpp(Revision 18599)
+++ src/Text.cpp(Arbeitskopie)
@@ -1330,8 +1331,10 @@
Stefan Schimanski wrote:
Am 31.05.2007 um 22:54 schrieb Dov Feldstern:
Stefan Schimanski wrote:
Am 31.05.2007 um 22:27 schrieb Stefan Schimanski:
The patch:
Index: src/Text.cpp
===
--- src/Text.cpp(Revision 18599)
+++ src
Stefan Schimanski wrote:
Am 31.05.2007 um 22:27 schrieb Stefan Schimanski:
The patch:
Index: src/Text.cpp
===
--- src/Text.cpp(Revision 18599)
+++ src/Text.cpp(Arbeitskopie)
@@ -1330,8 +1331,10 @@
checkBufferStruc
Am 31.05.2007 um 22:54 schrieb Dov Feldstern:
Stefan Schimanski wrote:
Am 31.05.2007 um 22:27 schrieb Stefan Schimanski:
The patch:
Index: src/Text.cpp
===
--- src/Text.cpp(Revision 18599)
+++ src/Text.cpp(Arbeitskopie)
Stefan Schimanski wrote:
Am 31.05.2007 um 22:27 schrieb Stefan Schimanski:
The patch:
Index: src/Text.cpp
===
--- src/Text.cpp(Revision 18599)
+++ src/Text.cpp(Arbeitskopie)
@@ -1330,8 +1331,10 @@
checkBufferStruc
Stefan Schimanski wrote:
Ok, makes sense. The character then entered should be with the font of
the character at that position.
Stefan --- once you're at it, should Text2.cpp:768 (in setCurrentFont)
be changed:
- if ((pos > 0 && cur.boundary()) || pos == cur.lastpos())
--pos;
+ if
Am 31.05.2007 um 22:27 schrieb Stefan Schimanski:
The patch:
Index: src/Text.cpp
===
--- src/Text.cpp(Revision 18599)
+++ src/Text.cpp(Arbeitskopie)
@@ -1330,8 +1331,10 @@
checkBufferStructure(cur.b
The patch:
Index: src/Text.cpp
===
--- src/Text.cpp(Revision 18599)
+++ src/Text.cpp(Arbeitskopie)
@@ -1330,8 +1331,10 @@
checkBufferStructure(cur.buffer(), cur);
}
- if (cur.pos() == cur
Am 31.05.2007 um 22:10 schrieb Dov Feldstern:
Dov Feldstern wrote:
Dov Feldstern wrote:
Dov Feldstern wrote:
Anyhow, to reproduce:
1) type a long long string with no space, until it breaks to the
next line.
2) from the last position in the paragraph (it only works from
there) start bac
Dov Feldstern wrote:
Dov Feldstern wrote:
Dov Feldstern wrote:
Anyhow, to reproduce:
1) type a long long string with no space, until it breaks to the next
line.
2) from the last position in the paragraph (it only works from there)
start backspacing. When you try to delete the last remaining
Stefan Schimanski wrote:
Here is a patch for #3466 (http://bugzilla.lyx.org/show_bug.cgi?id=3466).
Is the call of updateFlags ok?
Yes.
Wondering if we get two redraws here
instead of one if e.g. you close a macro with space.
No, there'll be only one redraw in principle.
OK, I suppose you
Here is a patch for #3466 (http://bugzilla.lyx.org/show_bug.cgi?
id=3466).
Is the call of updateFlags ok? Wondering if we get two redraws here
instead of one if e.g. you close a macro with space.
This attempt to avoid recursive macros should be obsolete now.
SVN commit log:
If the cursor is c
Angus Leeming wrote:
> Aren't these things frustrating though!
>
> Is it expensive to access things like
> Paragraph & par = cur.paragraph();
> pit_type pit = cur.pit();
> If not, then it would be bast to just remove the short cuts, no?
Make up your mind already! ;-)
If you refer to th
Alfredo Braunstein wrote:
>> + // Redefine the par reference because modification of
>> + // the cursor has invalidated the original.
>> + Paragraph const & par = cur.paragraph();
> Ok, I'll apply that.
> Alfredo
Aren't these things frustrating though!
Is it e
Angus Leeming wrote:
> +ÂÂÂ//ÂRedefineÂtheÂparÂreferenceÂbecauseÂmodificationÂofÂthe
> +ÂÂÂ//ÂcursorÂhasÂinvalidatedÂtheÂoriginal.
> +ÂÂÂParagraphÂconstÂ&ÂparÂ=Âcur.paragraph();
>
Ok, I'll apply that.
Alfredo
Alfredo Braunstein wrote:
> Pretty straightforward. Ok?
Your patch is obviously correct. Perhaps some documentation would explain
why?
} else if (cur.pit() > 0) {
--cur.pit();
+ // Redefine the par reference because modification of the
+ // cursor has invalidated the ori
Pretty straightforward. Ok?
btw, any idea about the crashes (unusable -- lyx-xforms crashes on startup
for instance) with --enable-stdlib-debug? Are these real lyx errors or
something is wrong in my setup?
Alfredo
Index: ChangeLog
Andre Poenitz wrote:
> I just wonder why a variable is called 'dummy' if it is used in two
> places...
;-) an that was only a small snippet! The converter code is really horrible.
Alfredo
I just wonder why a variable is called 'dummy' if it is used in two
places...
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Ok?
[to be true, this code is really ugly: all works because the buffer argument
seems not used when the conversion is from latex. but I'm not touching it
right now...]
Alfredo
? bfri.C
Index: ChangeLog
===
RCS file: /usr/local/lyx/c
On Mon, Nov 10, 2003 at 01:09:55PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> > But I just noticed we need to a bit more careful: If an inset is not
> >> > visible anymore (because the user scrolled down) it keeps its xy chace
> >> > with bogus values...
> >>
> >> Ugh...
> >
Andre Poenitz wrote:
>> > But I just noticed we need to a bit more careful: If an inset is not
>> > visible anymore (because the user scrolled down) it keeps its xy chace
>> > with bogus values...
>>
>> Ugh...
>
> We need the notion of 'visible paragraphs of main text'.
> BufferView::updateInset
On Mon, Nov 10, 2003 at 12:45:14PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> Compiling. Note that we should anyway assert on "no rows", be cause "no
> >> rows" means "no position information at all" so the checkInsetHit call
> >> would be completely bogus.
> >
> > No, it mean
On Mon, Nov 10, 2003 at 12:45:14PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> Compiling. Note that we should anyway assert on "no rows", be cause "no
> >> rows" means "no position information at all" so the checkInsetHit call
> >> would be completely bogus.
> >
> > No, it mean
Andre Poenitz wrote:
>> Compiling. Note that we should anyway assert on "no rows", be cause "no
>> rows" means "no position information at all" so the checkInsetHit call
>> would be completely bogus.
>
> No, it means 'no _internal_ position information'.
... what about the inset size? Height in
On Mon, Nov 10, 2003 at 12:33:03PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Something with that idea attached. It solves the particular problem and
> > seems to be a proper solutuion. And removes 30 lines...
> >
> > Note that we now simply iterator over the insetlist and do n
Andre Poenitz wrote:
> Something with that idea attached. It solves the particular problem and
> seems to be a proper solutuion. And removes 30 lines...
>
> Note that we now simply iterator over the insetlist and do not need the
> row structure anymore.
Compiling. Note that we should anyway asse
On Mon, Nov 10, 2003 at 11:31:55AM +0100, Alfredo Braunstein wrote:
> Maybe:
>
> while ((inset_hit = text->checkInsetHit(x, y))) {
> + if (!inset_hit->isHiglyEditable())
> + break;
> inset = inset_hit;
>
On Mon, Nov 10, 2003 at 11:11:41AM +0100, Andre Poenitz spake thusly:
>
> On Mon, Nov 10, 2003 at 11:04:44AM +0100, Alfredo Braunstein wrote:
> > Open the UG, click on the first footnote -> crash
> >
> > The problem is that the bv_owner of the text is set on InsetText::dispatch,
> > but the inset
Andre Poenitz wrote:
> return 0?
I don't understand, how do you click on button insets (or closed
collapsables) if they are not hit by insetFromCoords?
The inset *has* to be hit, it's the lyxtext inside that is "not present".
Maybe:
while ((inset_hit = text->checkInsetHit(x, y
On Mon, Nov 10, 2003 at 11:14:28AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Would just setting the view be enough?
>
> Probably not, as LyXText::checkInsetHit needs a RowList. But I think it's
> wrong in any case to call it, see my other post.
Hm.. iterating over the insetl
Andre Poenitz wrote:
> Would just setting the view be enough?
Probably not, as LyXText::checkInsetHit needs a RowList. But I think it's
wrong in any case to call it, see my other post.
Alfredo
On Mon, Nov 10, 2003 at 11:10:23AM +0100, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > The attached solves it, even if it doesn't seem the right solution.
>
> There is an architectural problem here: the Cursor doesn't know that the
> inset is collapsed and tries to go further down.
Alfredo Braunstein wrote:
> The attached solves it, even if it doesn't seem the right solution.
There is an architectural problem here: the Cursor doesn't know that the
inset is collapsed and tries to go further down.
Maybe checkInsetHit still needs to be recursive after all.
Regards, Alfredo
On Mon, Nov 10, 2003 at 11:04:44AM +0100, Alfredo Braunstein wrote:
> Open the UG, click on the first footnote -> crash
>
> The problem is that the bv_owner of the text is set on InsetText::dispatch,
> but the insetHist check is done before that.
>
> The attached solves it, even if it doesn't see
Open the UG, click on the first footnote -> crash
The problem is that the bv_owner of the text is set on InsetText::dispatch,
but the insetHist check is done before that.
The attached solves it, even if it doesn't seem the right solution.
bv_owner -> bv() changes were good to find the crash.
In
On Thu, Nov 06, 2003 at 12:22:14PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> - trying to insert an inset, inside an inset, inside an inset exits the
> >> second one and does nothing.
> >
> > That's strange as current CVS uses the old dispatch route...
>
> Better stated: put
Andre Poenitz wrote:
>> - trying to insert an inset, inside an inset, inside an inset exits the
>> second one and does nothing.
>
> That's strange as current CVS uses the old dispatch route...
Better stated: put a text-inset inside another text-inset and put the cursor
there.
Then almost every e
On Tue, Nov 04, 2003 at 10:58:53PM +0100, Alfredo Braunstein wrote:
> - searching on inside an insetext leads to a crash (assert on the
> uninitialized bv cache in insettext).
> - collapsables are not open on edit() as they should.
>
> Can I apply the attached? (should I just wait to the IL stuff
- searching on inside an insetext leads to a crash (assert on the
uninitialized bv cache in insettext).
- collapsables are not open on edit() as they should.
Can I apply the attached? (should I just wait to the IL stuff to die, or we
are trying to keep the thing alive on the transition?)
dispatch
On Tue, Apr 30, 2002 at 11:57:11PM +0300, Dekel Tsur wrote:
> > Crashes with the attached file !
>
> As far as I can tell, the bug is not in my code.
Didn't look like it.
> The crash occurs when trying to clone an insettext which contains a graphics.
Wouldn't this mean undo would crash too ?
On Tue, Apr 30, 2002 at 06:06:35PM +0100, John Levon wrote:
> On Tue, Apr 30, 2002 at 04:59:17PM +0300, Dekel Tsur wrote:
>
> > > > So I call others to test it.
>
> Crashes with the attached file !
As far as I can tell, the bug is not in my code.
The crash occurs when trying to clone an insette
On Tue, Apr 30, 2002 at 04:59:17PM +0300, Dekel Tsur wrote:
> > > So I call others to test it.
Crashes with the attached file !
john
--
"Please let's not resume the argument with the usual whining about how this
feature will wipe out humanity or bring us to the promised land."
- Charl
58 matches
Mail list logo
