[PATCH] Re: Format=>Document=>Page size not working
Herbert Voß wrote:
> aehm, nevertheless, it seems to be a qt-bug ...
Attached is the fix for 1.3.4 (I can't compile 1.4 right now).
Jean-Marc, can this go in?
Jürgen
Index: src/frontends/qt2/QDocument.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QDocument.C,v
retrieving revision 1.33.2.5
diff -u -r1.33.2.5 QDocument.C
--- src/frontends/qt2/QDocument.C 19 Nov 2003 16:32:49 - 1.33.2.5
+++ src/frontends/qt2/QDocument.C 4 Dec 2003 09:46:43 -
@@ -306,6 +306,10 @@
params.papersize2 =
dialog_->paperModule->papersizeCO->currentItem();
+ // custom, A3, B3 and B4 paper sizes need geometry
+ int psize = dialog_->paperModule->papersizeCO->currentItem();
+ bool geom_papersize = (psize == 1 || psize == 5 || psize == 8 || psize == 9);
+
params.paperwidth = widgetsToLength(dialog_->paperModule->paperwidthLE,
dialog_->paperModule->paperwidthUnitCO);
@@ -329,7 +333,8 @@
// margins
params.use_geometry =
- (dialog_->marginsModule->marginCO->currentItem() == 1);
+ (dialog_->marginsModule->marginCO->currentItem() == 1
+ || geom_papersize);
int margin = dialog_->marginsModule->marginCO->currentItem();
if (margin > 0) {
Re: Qt external dialog is ready for use
Angus Leeming wrote: > Patch and screen shot attached. and just so the xforms world doesn't feel left out, I've finished that dialog too. Patch attached FYI. -- Angus xforms.diff.bz2 Description: BZip2 compressed data
Re: feature request
Andre Poenitz wrote: > On Wed, Dec 03, 2003 at 10:04:17PM +0100, Moritz Moeller-Herrmann wrote: >> Good to hear. Is lyx-1.4 stable enough already for a PHD with 300 pages? > > Not at all. > > [Btw whom do you expect to read a PhD thesis with 300 pages?] In law, PhDs are about 200-300 pages long, normally. So hopefully my supervisor and some people in the ministry of health in Germany. I'll send you a copy, when it's done, if you want.
Re: Qt external dialog is ready for use
On Thursday 04 December 2003 11:30 pm, John Levon wrote:
> On Thu, Dec 04, 2003 at 07:44:56PM +, Angus Leeming wrote:
> > Patch and screen shot attached.
>
> A bit hard to see !
I didn't want to swamp the list with a huge screendump.
> What's the red in the dialog ? Baaddd...
;-) It's a bit of fun. The primary purpose of CheckedLineEdit is to ensure
that the 'Apply' and 'Ok' buttons are disabled if you've input some nonsense
in one of the QLineEdits. They will remain disabled even if you go elsewhere
and play with another part of the dialog.
That said, I think it makes sense to provide the user with a visual clue that
of where's he's going wrong.
So, 'hard coding 'Red' is 'Baaddd...', but the rest isn't.
namespace {
void setWidget(bool valid, QLineEdit * input, QLabel * label)
{
QColor const red(255, 0, 0);
if (valid)
input->unsetPalette();
else
input->setPaletteForegroundColor(red);
if (!label)
return;
if (valid)
label->unsetPalette();
else
label->setPaletteForegroundColor(red);
}
} // namespace anon
CheckedLineEdit::CheckedLineEdit(QLineEdit * input, QLabel * label)
: input_(input), label_(label)
{}
bool CheckedLineEdit::check() const
{
QString t = input_->text();
int p = 0;
QValidator const * validator = input_->validator();
if (!validator)
return true;
bool const valid = validator->validate(t, p) == QValidator::Acceptable;
// Visual feedback.
setWidget(valid, input_, label_);
return valid;
}
Re: Qt external dialog is ready for use
On Thu, Dec 04, 2003 at 07:44:56PM +, Angus Leeming wrote: > Patch and screen shot attached. A bit hard to see ! What's the red in the dialog ? Baaddd... john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [PATCH] Re: Format=>Document=>Page size not working
On Thu, Dec 04, 2003 at 05:53:18PM +0100, Juergen Spitzmueller wrote: > Herbert Voß wrote: > > aehm, nevertheless, it seems to be a qt-bug ... > > Attached is the fix for 1.3.4 (I can't compile 1.4 right now). > Jean-Marc, can this go in? My question (for 1.4.0cvs) would be why this isn't entirely within the controller ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
[PATCH] Re: Format=>Document=>Page size not working
Herbert Voß wrote:
> aehm, nevertheless, it seems to be a qt-bug ...
Attached is the fix for 1.3.4 (I can't compile 1.4 right now).
Jean-Marc, can this go in?
Jürgen
Index: src/frontends/qt2/QDocument.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QDocument.C,v
retrieving revision 1.33.2.5
diff -u -r1.33.2.5 QDocument.C
--- src/frontends/qt2/QDocument.C 19 Nov 2003 16:32:49 - 1.33.2.5
+++ src/frontends/qt2/QDocument.C 4 Dec 2003 09:46:43 -
@@ -306,6 +306,10 @@
params.papersize2 =
dialog_->paperModule->papersizeCO->currentItem();
+ // custom, A3, B3 and B4 paper sizes need geometry
+ int psize = dialog_->paperModule->papersizeCO->currentItem();
+ bool geom_papersize = (psize == 1 || psize == 5 || psize == 8 || psize == 9);
+
params.paperwidth = widgetsToLength(dialog_->paperModule->paperwidthLE,
dialog_->paperModule->paperwidthUnitCO);
@@ -329,7 +333,8 @@
// margins
params.use_geometry =
- (dialog_->marginsModule->marginCO->currentItem() == 1);
+ (dialog_->marginsModule->marginCO->currentItem() == 1
+ || geom_papersize);
int margin = dialog_->marginsModule->marginCO->currentItem();
if (margin > 0) {
[PATCH] qbox
I have tried to make the ui as simple and intuitive as possible. Therefore the code may look a bit tricky (but it works in all cases afaict). And another small enhancement to lengthcombo was needed. Hope you like it. I will apply during the weekend if I get no objections. Jürgen qbox.diff.gz Description: GNU Zip compressed data
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 06:25:24PM +0100, Michael Schmitt spake thusly:
> Jean-Marc Lasgouttes wrote:
>
> > Martin> Talking about looks, see the attached.
>
> Looks good, Martin!
>
> >
> > |some contents here|
> > name
> >
> > This would reduce the height of the inset...
>
>
> > You can even do
> > some contents here
> > \---name-/
> > and avoid the frame altogether.
>
> Ha! That was exactly _my_ idea (about 15 seconds ago) :-)
>
> I think the red frame should be removed, if possible, since (a) it
> occupies some space and (b) looks too eye-catching.
>
> However, we might need the red box for insets that span more than one
> row. Martin, can we check whether an inset is a one-liner or not and
> output it differently in both possible cases? That would be (nearly)
> perfect!
>
> Michael
That isn't quite so easy... feel free to try ;-)
I tightened up the thing a little bit. The patch is attached.
I think this is such a clear improvement on what we had, that this
should go in as it stands, despite small quirks (which I am not even
sure have to do with the patch). I think we have at least the right
visual model now.
- Martin
Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.7
diff -u -p -r1.7 insetcharstyle.C
--- insetcharstyle.C1 Dec 2003 16:01:50 - 1.7
+++ insetcharstyle.C4 Dec 2003 21:31:08 -
@@ -25,6 +25,8 @@
#include "metricsinfo.h"
#include "paragraph.h"
+#include "frontends/font_metrics.h"
+#include "frontends/Painter.h"
#include "support/std_sstream.h"
@@ -38,13 +40,13 @@ using std::ostringstream;
void InsetCharStyle::init()
{
setInsetName("CharStyle");
- setButtonLabel();
+ setStatus(Inlined);
}
InsetCharStyle::InsetCharStyle(BufferParams const & bp,
CharStyles::iterator cs)
- : InsetCollapsable(bp)
+ : InsetCollapsable(bp), has_label_(true)
{
params_.type = cs->name;
params_.latextype = cs->latextype;
@@ -57,7 +59,7 @@ InsetCharStyle::InsetCharStyle(BufferPar
InsetCharStyle::InsetCharStyle(InsetCharStyle const & in)
- : InsetCollapsable(in), params_(in.params_)
+ : InsetCollapsable(in), params_(in.params_), has_label_(true)
{
init();
}
@@ -85,24 +87,41 @@ void InsetCharStyle::write(Buffer const
void InsetCharStyle::read(Buffer const & buf, LyXLex & lex)
{
InsetCollapsable::read(buf, lex);
- setButtonLabel();
+ setStatus(Inlined);
}
-void InsetCharStyle::setButtonLabel()
+void InsetCharStyle::metrics(MetricsInfo & mi, Dimension & dim) const
{
- LyXFont font(params_.labelfont);
- font.realize(LyXFont(LyXFont::ALL_SANE));
- string const s = "Style: " + params_.type;
- setLabel(isOpen() ? s : getNewLabel(s) );
- setLabelFont(font);
+ InsetCollapsable::metrics(mi, dim);
+ dim_ = dim;
+ if (has_label_)
+ dim_.des += ascent();
}
-void InsetCharStyle::metrics(MetricsInfo & mi, Dimension & dim) const
+void InsetCharStyle::draw(PainterInfo & pi, int x, int y) const
{
- InsetCollapsable::metrics(mi, dim);
- dim_ = dim;
+ xo_ = x;
+ yo_ = y;
+
+ status_ = Inlined;
+ InsetCollapsable::draw(pi, x, y);
+ if (has_label_) {
+ if (!owner())
+ x += scroll();
+ LyXFont font;
+ font.setColor(LColor::blue);
+ font.realize(LyXFont(LyXFont::ALL_SANE));
+ font.decSize();
+ font.decSize();
+ int w = 0;
+ int a = 0;
+ int d = 0;
+ font_metrics::rectText(params_.type, font, w, a, d);
+ pi.pain.rectText(x + 0.5 * (dim_.wid - w), y + inset.descent() + a,
+ params_.type, font, LColor::none, LColor::none);
+ }
}
@@ -116,9 +135,17 @@ DispatchResult
InsetCharStyle::priv_dispatch(FuncRequest const & cmd,
idx_type & idx, pos_type & pos)
{
- DispatchResult dr = InsetCollapsable::priv_dispatch(cmd, idx, pos);
- setButtonLabel();
- return dr;
+ setStatus(Inlined);
+ switch (cmd.action) {
+ case LFUN_MOUSE_PRESS:
+ if (cmd.button() == mouse_button::button3) {
+ has_label_ = !has_label_;
+ return DispatchResult(true);
+ }
+ default:
+ inset.dispatch(cmd);
+ return DispatchResult(true, true);
+ }
}
pgp0.pgp
Description: PGP signature
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 03:48:11PM -0300, Alfredo Braunstein wrote: > If some inset *after* gets into the row or not determines the position of > some inset in the row (before), don't you agree? Oh, yes john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Inline-Mode for InsetCollapsable
John Levon wrote: > Why ? If I start at the top, then inset + 1 can know its absolute > position surely, since all insets before have been calculated. for instance rebreaking cannot be done without knowing all insets in the paragraph (in the worst case)... If some inset *after* gets into the row or not determines the position of some inset in the row (before), don't you agree? Alfredo
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 02:54:14PM -0300, Alfredo Braunstein wrote: > no, the parent-relative position of the inset depends on it's own size *and* > other insets sizes at the same level (moreover, before *and* after it), and Why after ? I can't think of a case (well, tables, but that's all in one inset and can be handled as such) > it's computed by the parent. Furthemore, the absolute position is not known > until the end. Why ? If I start at the top, then inset + 1 can know its absolute position surely, since all insets before have been calculated. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Insertion of inset makes LyX crash
On Thu, Dec 04, 2003 at 06:22:55PM +, Angus Leeming wrote: > On Thursday 04 December 2003 6:03 pm, Kayvan A. Sylvan wrote: > > On Thu, Dec 04, 2003 at 05:39:09PM +, Angus Leeming wrote: > > > Angus Leeming wrote: > > > > I suspect that the crashing will go away if you revert André's two > > > > patches of yesterday evening. > > > > > > It looks like the fault lies with the second of the two patches. > > > > > > $ cvs2 -q diff -D "2003-12-3 18:00" -D "2003-12-3 19:00" > tmp.diff > > Can you send your patch file (tmp.diff) from above? Mine comes out empty. > > I suspect that it is time-zone dependent. Anyway, attached. Yes. This works for me: cvs diff -u -D "2003-12-3 18:00:00 GMT" -D "2003-12-3 19:00:00 GMT" Thanks! ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: Insertion of inset makes LyX crash
On Thursday 04 December 2003 6:03 pm, Kayvan A. Sylvan wrote: > On Thu, Dec 04, 2003 at 05:39:09PM +, Angus Leeming wrote: > > Angus Leeming wrote: > > > I suspect that the crashing will go away if you revert André's two > > > patches of yesterday evening. > > > > It looks like the fault lies with the second of the two patches. > > > > $ cvs2 -q diff -D "2003-12-3 18:00" -D "2003-12-3 19:00" > tmp.diff > > $ patch -p0 -R < tmp.diff > > > > Fixes things for me. > > Can you send your patch file (tmp.diff) from above? Mine comes out empty. I suspect that it is time-zone dependent. Anyway, attached. andre1.diff.bz2 Description: BZip2 compressed data
Re: Insertion of inset makes LyX crash
On Thu, Dec 04, 2003 at 05:39:09PM +, Angus Leeming wrote: > Angus Leeming wrote: > > I suspect that the crashing will go away if you revert André's two > > patches of yesterday evening. > > It looks like the fault lies with the second of the two patches. > > $ cvs2 -q diff -D "2003-12-3 18:00" -D "2003-12-3 19:00" > tmp.diff > $ patch -p0 -R < tmp.diff > > Fixes things for me. Can you send your patch file (tmp.diff) from above? Mine comes out empty. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: Inline-Mode for InsetCollapsable
John Levon wrote:
> OK, can you explain why we don't update the positions in stage 1 then ?
> Isn't everything before the inset that could affect position updated by
> then ?
no, the parent-relative position of the inset depends on it's own size *and*
other insets sizes at the same level (moreover, before *and* after it), and
it's computed by the parent. Furthemore, the absolute position is not known
until the end.
IUC, this is how it goes:
inset::stage1
{
parent call children::stage1
parent compute own size/geometry
then parent know *relative* child positions (but not own position, so not
absolute child position)
}
only when the full metric stage is finished is that every absolute position
can possibly be known.
at least that's my understanding. ;-)
Alfredo
Re: Insertion of inset makes LyX crash
Angus Leeming wrote: > I suspect that the crashing will go away if you revert André's two > patches of yesterday evening. It looks like the fault lies with the second of the two patches. $ cvs2 -q diff -D "2003-12-3 18:00" -D "2003-12-3 19:00" > tmp.diff $ patch -p0 -R < tmp.diff Fixes things for me. -- Angus
Re: CharStyle discussion
Jean-Marc Lasgouttes wrote: Martin> Talking about looks, see the attached. Looks good, Martin! |some contents here| name This would reduce the height of the inset... You can even do some contents here \---name-/ and avoid the frame altogether. Ha! That was exactly _my_ idea (about 15 seconds ago) :-) I think the red frame should be removed, if possible, since (a) it occupies some space and (b) looks too eye-catching. However, we might need the red box for insets that span more than one row. Martin, can we check whether an inset is a one-liner or not and output it differently in both possible cases? That would be (nearly) perfect! Michael
Re: Insertion of inset makes LyX crash
Kayvan A. Sylvan wrote: > I am getting this on trying to load a file I was able to edit > yesterday: > > $ lyx fsmon.lyx > BufferView::Pimpl::fitCursor. > Assertion triggered in T& boost::optional::operator*() [with T = > int] by fai ing check "m_initialized" in file > ../../lyx/boost/boost/optional.hpp:193 Aborted (core dumped) > > Do you think this is related? > > I can't produce a backtrace on this machine, but I may be able to > recreate the problem somewhere else. I suspect that the crashing will go away if you revert André's two patches of yesterday evening. $ cvs2 -q diff -D "2003-12-3 16:00" -D "2003-12-3 20:00" > tmp.diff $ patch -p0 -R < tmp.diff I'm going to do this myself, one patch at a time till I track down the offender. -- Angus
Re: CharStyle discussion
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Thu, Dec 04, 2003 at 03:55:40PM +, John Levon spake Martin> thusly: >> On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: >> >> > Shouldn't we concentrate on bug fixing rather than starting new >> projects? >> >> I think we're all agreed that the current char style stuff (modulo >> some minor changes in the way the insets look) should stay as is >> for now. Martin> Talking about looks, see the attached. What about putting the blue label on the frame of the inset like |some contents here| name This would reduce the height of the inset... You can even do some contents here \---name-/ and avoid the frame altogether. JMarc
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 07:14:18PM +0200, Martin Vermeer wrote: > Talking about looks, see the attached. Looks good regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 03:55:40PM +, John Levon spake thusly: > On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: > > > Shouldn't we concentrate on bug fixing rather than starting new projects? > > I think we're all agreed that the current char style stuff (modulo some > minor changes in the way the insets look) should stay as is for now. Talking about looks, see the attached. I need to do some cleaning on the patch still, but this works, and not just sort-of. What is unelegant about it is that it still bases CharStyle on Collapsable, though it is forced permanently into Inlined mode. There should be a way to base it directly off UpdatableInset (right?) but I didn't get anywhere trying. You remove/restore the blue label by right mouse clicking the inset. Not very discoverable but I'm sure we can work on that :-) - Martin <> pgp0.pgp Description: PGP signature
Re: Insertion of inset makes LyX crash
Kayvan A. Sylvan wrote: > Assertion triggered in T& boost::optional::operator*() [with T = > int] by fai ing check "m_initialized" in file > ../../lyx/boost/boost/optional.hpp:193 Aborted (core dumped) > Do you think this is related? Yes. -- Angus
Re: Insertion of inset makes LyX crash
On Thu, Dec 04, 2003 at 04:42:47PM +, Angus Leeming wrote: > Michael Schmitt wrote: > > > Hi, > > > > does anybody know why the insertion of an arbitrary inset makes LyX > > crash? > > If you kept the rest of the backtrace, you'd see that the culprit was > parInsetIterator or some such. I am getting this on trying to load a file I was able to edit yesterday: $ lyx fsmon.lyx BufferView::Pimpl::fitCursor. Assertion triggered in T& boost::optional::operator*() [with T = int] by fai ing check "m_initialized" in file ../../lyx/boost/boost/optional.hpp:193 Aborted (core dumped) Do you think this is related? I can't produce a backtrace on this machine, but I may be able to recreate the problem somewhere else. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: Insertion of inset makes LyX crash
Michael Schmitt wrote: > Hi, > > does anybody know why the insertion of an arbitrary inset makes LyX > crash? If you kept the rest of the backtrace, you'd see that the culprit was parInsetIterator or some such. -- Angus
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 05:11:06PM +0100, Michael Schmitt spake thusly: > > Michael Schmitt wrote: > > > John Levon wrote: > > > >> I think we're all agreed that the current char style stuff (modulo some > >> minor changes in the way the insets look) should stay as is for now. > > > Which char styles are supported at the moment? > > [EMAIL PROTECTED]:~/lyx-devel-1.4.0-devel/lib/layouts> grep Char * > agu_stdclass.inc:CharStyle Firstname > agu_stdclass.inc:CharStyle Surname > agu_stdclass.inc:CharStyle Filename > agu_stdclass.inc:CharStyle Literal > db_stdclass.inc:CharStyle Filename > db_stdclass.inc:CharStyle Firstname > db_stdclass.inc:CharStyle Surname > db_stdclass.inc:CharStyle Literal > stdclass.inc:CharStyle Noun > > For LyX 1.4, shouldn't we better remove the CharStyle "Noun" from > stdclass.inc again? The rest is less controversial. > > Michael I support that (throwing out Noun, that is). I built CharStyle (i.e., Element) for XML and tried to slip it past Lars. I failed :-( and so it became a multi-backend thing. The rest is history. - Martin pgp0.pgp Description: PGP signature
Re: why not report a problem (was Re: The current char style UI)
On Thu, Dec 04, 2003 at 03:09:20AM +0100, Christian Ridderstr?m wrote: > I recognise several of these from my personal experience with LyX, but > let me add that on several occasions I've simply thought that: > > "ok, there's this little problem, but who cares, LyX is still so good" people should try and make an effort to complain about even the most minor of things :) Someone has to take the heat off me ! regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 12:12:13AM -0300, Alfredo Braunstein wrote: > > Why is draw() updating anything ? Shouldn't that be in the stage before > > the actual draw() ? draw() should be logically const, no ? > > But we have a two stages mechanism: dimensions are computed on the first > stage, positions on the second stage (which happends also to be the draw > stage). You could also introduce a nominal third one if you want, i.e. > > metrics > positions > draw > > but we are just grouping the last two ones in "draw" OK, can you explain why we don't update the positions in stage 1 then ? Isn't everything before the inset that could affect position updated by then ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: gnu make-isms
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> SUFFIX = .C .fd Angus> .fd.C: $(SHELL) $(SCRIPT) $< Angus> Patch attached. Ok to apply to 13x, Jean-Marc? Yes. JMarc
Re: CharStyle discussion
Michael Schmitt wrote: John Levon wrote: I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. > Which char styles are supported at the moment? [EMAIL PROTECTED]:~/lyx-devel-1.4.0-devel/lib/layouts> grep Char * agu_stdclass.inc:CharStyle Firstname agu_stdclass.inc:CharStyle Surname agu_stdclass.inc:CharStyle Filename agu_stdclass.inc:CharStyle Literal db_stdclass.inc:CharStyle Filename db_stdclass.inc:CharStyle Firstname db_stdclass.inc:CharStyle Surname db_stdclass.inc:CharStyle Literal stdclass.inc:CharStyle Noun For LyX 1.4, shouldn't we better remove the CharStyle "Noun" from stdclass.inc again? The rest is less controversial. Michael
Re: CharStyle discussion
On Thursday 04 December 2003 15:17, Michael Schmitt wrote: > Dear Martin et al., > > do you need some more comments? Ok, here are mine :-) Good to hear. > > Yes, box removing by is 'direct manipulation' according to > > this definition. > > > > Nobody, not a single person! complained about this since 1.3.0 is out. > > I am really tempted to call this argument 'FUD'. > > Personally, I have no problem with this feature. Although I consider > myself a power-user, I have never noticed it in mathed. This also means > that it has never been an obstacle when writing some formula :-) > > HOWEVER... and now I will make you very angry ... I don't like the > CharStyle inset approach at all - at least in the way it is planned at > the moment. You don't make us angry just be disagreeing with us. :-) > Insets are an appropriate means for structured editing but they are not > suitable for writing consecutive text. If I had had to insert an inset > for every emphasized term, for every capitalized product name, for every > keyword in typewriter font, and for every figure reference in sans serif > in my PhD, I would have jumped out of the window!!! The LyX motto "WYSIWM" it is not really implemented at moment. And one of the reasons is because we lake the logical char styles. In several aspects we still encourage the user to think about italics, capitalized, typewriter and sans serif. Notice that you used those words instead of their concepts above. What if suddenly you want to change that to a new style, what do you do? I know that we should have some kind of compromise, but you seem to be pushing it to WYSIWYG. > But instead of starting a discussion on how to display insets in the > most comfortable way, we have to clarify the general concepts of > character styles first. The point again is that the insets are an implementation detail. And courageous step, IMHO, in the right direction. Also you will not be forced to use them, they are really usefull at this moment for linuxdoc, docbook and AGU. Yes, they are usefull also to latex, but for the other fontends they are a must have. We have been discussing this for the last 4 years (at least). And Martin showed a simple self-contained approach, the amount of code needed is minimal, and non-intrusive. > IMHO there should be no fixed set of char styles. > Instead the user should be able to define his own styles and > change them later (similar to branches). This, of course, requires > additional dialogs, etc. etc. That was of the goals stated by Martin since the first hour. And we need to start somewhere... > So... do we really want such a mammoth project while LyX is broken at > each corner? Last night, I worked four hours on a simple > insetcollapsable/insertert code merge just to find out that the crashes > I experienced also occur with the latest cvs :-( (The fact that my 1Ghz > 128MB computer spent more than half of the time on compiling and > swapping did not improve my bad mood). That is always the question of the 90%-10%. They also very useful as they are an can be improved for sure. > Shouldn't we concentrate on bug fixing rather than starting new projects? I think that Martin, André or me have been fixing our share of bugs. (Is there such a thing? ;-) ). > Michael PS: Everything said should be taken with a grain of salt, or sugar, or chocolate or every if you prefer. ;-) -- José Abílio LyX and docbook, a perfect match. :-)
Insertion of inset makes LyX crash
Hi, does anybody know why the insertion of an arbitrary inset makes LyX crash? Michael LyXFunc::dispatch: cmd: action: 3 arg: '' x: 0 y: 0 BufferView::Pimpl::fitCursor. Redraw screen BufferView::Pimpl::fitCursor. Redraw screen LyXFunc::dispatch: cmd: action: 97 arg: 'Comment' x: 0 y: 0 LCursor::dispatch: trying to dispatch to main text 0x861e8a4 undo record: text: 0 index: 0 first: 0 from end: 1 cursor: 0/0 InsetCollapsable: edit left/right InsetText: edit left/right Assertion triggered in T& boost::optional::operator*() [with T = int] by failing check "m_initialized" in file ../boost/boost/optional.hpp:193 Abgebrochen
Re: The current char style UI
On Thu, Dec 04, 2003 at 11:49:03AM +0100, Andre Poenitz wrote: > Same argument as John's when he opposed equivalent changes in mathed. > Nobody, not a single person! complained about this since 1.3.0 is out. > I am really tempted to call this argument 'FUD'. Oh come on. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: CharStyle discussion
John Levon wrote: Shouldn't we concentrate on bug fixing rather than starting new projects? I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. That means existing documents will be converted? Which char styles are supported at the moment? We're talking about where it should go after. You mean after 1.4? Kind regards, Michael
Re: CharStyle discussion
On Thu, Dec 04, 2003 at 04:17:34PM +0100, Michael Schmitt wrote: > Shouldn't we concentrate on bug fixing rather than starting new projects? I think we're all agreed that the current char style stuff (modulo some minor changes in the way the insets look) should stay as is for now. We're talking about where it should go after. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: The current char style UI
On Thu, Dec 04, 2003 at 10:43:34AM +0100, Andre Poenitz wrote: > Having it in the menu would make it discoverable, describing it in the > UserGuide is sufficient in my opinion. Then we have reached a complete impasse, alas. At christmas. > > http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=200 > > > > (Actually by that rather strict definition, neither way is, but > > certainly mine is a lot closer) > > Yes, box removing by is 'direct manipulation' according to > this definition. It's clearly not :) regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
CharStyle discussion
Dear Martin et al., do you need some more comments? Ok, here are mine :-) > Yes, box removing by is 'direct manipulation' according to > this definition. > Nobody, not a single person! complained about this since 1.3.0 is out. > I am really tempted to call this argument 'FUD'. Personally, I have no problem with this feature. Although I consider myself a power-user, I have never noticed it in mathed. This also means that it has never been an obstacle when writing some formula :-) HOWEVER... and now I will make you very angry ... I don't like the CharStyle inset approach at all - at least in the way it is planned at the moment. Insets are an appropriate means for structured editing but they are not suitable for writing consecutive text. If I had had to insert an inset for every emphasized term, for every capitalized product name, for every keyword in typewriter font, and for every figure reference in sans serif in my PhD, I would have jumped out of the window!!! But instead of starting a discussion on how to display insets in the most comfortable way, we have to clarify the general concepts of character styles first. IMHO there should be no fixed set of char styles. Instead the user should be able to define his own styles and change them later (similar to branches). This, of course, requires additional dialogs, etc. etc. So... do we really want such a mammoth project while LyX is broken at each corner? Last night, I worked four hours on a simple insetcollapsable/insertert code merge just to find out that the crashes I experienced also occur with the latest cvs :-( (The fact that my 1Ghz 128MB computer spent more than half of the time on compiling and swapping did not improve my bad mood). Shouldn't we concentrate on bug fixing rather than starting new projects? Michael
Re: feature request
On Thu, 4 Dec 2003, Andre Poenitz wrote: > [Btw whom do you expect to read a PhD thesis with 300 pages?] > His supervisor? Nah... he won't bother ;-) /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 12:56:57PM +, Angus Leeming wrote: > On Thursday 04 December 2003 12:54 pm, Andre Poenitz wrote: > > On Thu, Dec 04, 2003 at 01:34:29AM +, Angus Leeming wrote: > > > Alfredo Braunstein wrote: > > > > John Levon wrote: > > > >> Strikes me as a highly dubious thing to do, but since I'm not doing > > > >> any > > > > > > > > Why? > > > > > > Actually, what would be nice is > > > > I hate this. > > Why? You prefer having 'xo_ = x; yo_ = y;' all over the place? No. Some new setPositionCache(x, y) immediately called before draw() would solve the same problem. > I don't since I find that _I_ have to add 'em to places you've > forgotten, else I can't open the dialog. > > > And I still hate Lars (for suitable values of 'hate') for doing this > > to dispatch(). > > [...snip rant...] > > C'mon, André, where's your sense of proportion? Why do you think I have such a thing? If there were such a thing it would be offended by having virtual DispatchResult priv_dispatch(FuncRequest const & cmd, idx_type & idx, pos_type & pos); instead of nice litlle DispatchResult dispatch(FuncRequest const & cmd); in 90% of the cases. > > Could you please postpone making such "nice" improvements as long as > > I am not finished with changes and fixes in this area? > > Stop being so touchy. It was a suggestion only. > Have a KitKat and a coffee and a smiile ;-) Angus No kitkat here. No coffee. No smile. Just lots of unneeded code. Andre' Btw: You know Pontius and Pilatus version 2003_de? A: Hey look, I've a document and a photocopy of it and _you_ want a stamp on the letter. So please check that they are identical and put a stamp of it. P0: Well, I could, if <102312 restrictions>. So go to P1 who issued the document. [A off to P1, 40 km] A: Hey look, I've got a document of yours and a photocopy of it. Would you please put a statement on the copy that it is a proper copy and a stamp or such? P1: I am not allowed to do so. A: But you issued the document. P1: Sure. I am allowed to do that, but not to stamp the copy. Go ask P2 or P3. A: P2 is 500 km away, I need it now [A Off to P3, just 3 km away] A: ... P3: Well, of course we could do that. Generally spoken. However, there are only two out of our 900+employees who are authorized. A: No problem, one is enough. P3: Well, one is sick, the other off for a holiday. Try P4. [A Off to P4, again 3 km, just around the corner of P2] Guess what. Happy end for EUR 2.50.
Re: Inline-Mode for InsetCollapsable
On Thursday 04 December 2003 1:17 pm, Andre Poenitz wrote: > Btw: You know Pontius and Pilatus version 2003_de? That explains a lot about your mood. Ughhh! You have my sympathies. A
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 02:17:16PM +0100, Andre' Poenitz wrote: > A: Hey look, I've a document and a photocopy of it and _you_ >want a stamp on the letter. 'latter', i.e. on the photocopy. Andre'
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 01:08:38PM +, Angus Leeming wrote: > On Thursday 04 December 2003 1:00 pm, Andre Poenitz wrote: > > On Thu, Dec 04, 2003 at 12:27:12PM +, Angus Leeming wrote: > > > > Better this way? > > > > > > Personal feeling? Yes, although my suggestion of draw, priv_draw would > > > result in only one virtual function here as opposed to your two. Perhaps > > > ;-) > > > > > > As for simple: I think that even the button insets need to set this. > > But MathCharInset cannot afford this, so it can't go to the base. > > It can't afford to set a cache? Why not? (curious) Because the cache cost 8 bytes. We don't want that for each character, especially if the character never ever will use the cached value. > > Btw that 'priv_' prefix is ugly. > > I am already seeing the day when we introduce hungarian notation in LyX. > > As a concession to new times maybe as namespaces > > ::lyx::insets::all_of_them::sort_of_private::i_mean_it::draw. > > Whatever. Did you have that coffee yet? I thought coffee works the other way? Andre'
Re: Inline-Mode for InsetCollapsable
On Thursday 04 December 2003 1:00 pm, Andre Poenitz wrote: > On Thu, Dec 04, 2003 at 12:27:12PM +, Angus Leeming wrote: > > > Better this way? > > > > Personal feeling? Yes, although my suggestion of draw, priv_draw would > > result in only one virtual function here as opposed to your two. Perhaps > > ;-) > > > > As for simple: I think that even the button insets need to set this. > But MathCharInset cannot afford this, so it can't go to the base. It can't afford to set a cache? Why not? (curious) > Btw that 'priv_' prefix is ugly. > I am already seeing the day when we introduce hungarian notation in LyX. > As a concession to new times maybe as namespaces > ::lyx::insets::all_of_them::sort_of_private::i_mean_it::draw. Whatever. Did you have that coffee yet? A
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 12:27:12PM +, Angus Leeming wrote: > > Better this way? > > Personal feeling? Yes, although my suggestion of draw, priv_draw would result > in only one virtual function here as opposed to your two. Perhaps ;-) > > As for simple: I think that even the button insets need to set this. But MathCharInset cannot afford this, so it can't go to the base. Btw that 'priv_' prefix is ugly. I am already seeing the day when we introduce hungarian notation in LyX. As a concession to new times maybe as namespaces ::lyx::insets::all_of_them::sort_of_private::i_mean_it::draw. Andre'
Re: Inline-Mode for InsetCollapsable
On Thursday 04 December 2003 12:54 pm, Andre Poenitz wrote: > On Thu, Dec 04, 2003 at 01:34:29AM +, Angus Leeming wrote: > > Alfredo Braunstein wrote: > > > John Levon wrote: > > >> Strikes me as a highly dubious thing to do, but since I'm not doing > > >> any > > > > > > Why? > > > > Actually, what would be nice is > > I hate this. Why? You prefer having 'xo_ = x; yo_ = y;' all over the place? I don't since I find that _I_ have to add 'em to places you've forgotten, else I can't open the dialog. > And I still hate Lars (for suitable values of 'hate') for doing this > to dispatch(). [...snip rant...] C'mon, André, where's your sense of proportion? > Could you please postpone making such "nice" improvements as long as I > am not finished with changes and fixes in this area? Stop being so touchy. It was a suggestion only. Have a KitKat and a coffee and a smiile ;-) Angus
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 01:34:29AM +, Angus Leeming wrote: > Alfredo Braunstein wrote: > > > John Levon wrote: > > > >> Strikes me as a highly dubious thing to do, but since I'm not doing > >> any > > > > Why? > > Actually, what would be nice is I hate this. And I still hate Lars (for suitable values of 'hate') for doing this to dispatch(). And as long as we are on it: I still hate the auto_ptr<> return from clone. All unnessecary verbosity for the sake of some kind of imagined political correctness. Could you please postpone making such "nice" improvements as long as I am not finished with changes and fixes in this area? Andre'
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 01:05:35AM +, John Levon wrote: > On Wed, Dec 03, 2003 at 10:04:17PM -0300, Alfredo Braunstein wrote: > > > > Strikes me as a highly dubious thing to do, but since I'm not doing any > > > > Why? > > Why is draw() updating anything ? It is updating the drawing position cache. The position cache is used for insetHit. > Shouldn't that be in the stage before > the actual draw() ? draw() should be logically const, no ? Except for updating the cache, yes. > I'd hate to see a return of CHANGED_IN_DRAW :) There is no such plan. Andre'
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 12:44:15AM +, John Levon wrote:
> On Wed, Dec 03, 2003 at 11:09:45PM +, Angus Leeming wrote:
>
> > Hi, joohn!
>
> Bah, my keyboard is dyiing :(
>
> > I've just regained the ability to hit InsetExternal by updating the
> > cache data. I suspect that other insets are missing this too.
> >
> > void InsetExternal::draw(PainterInfo & pi, int x, int y) const
> > {
> > + xo_ = x;
> > + yo_ = y;
> > renderer_->draw(pi, x, y);
>
> Strikes me as a highly dubious thing to do, but since I'm not doing any
> coding, I suppose I don't have a say ...
You certainly have a say, especially if you formulate it as
constructive criticism.
Andre'
Re: Inline-Mode for InsetCollapsable
On Thursday 04 December 2003 12:17 pm, Andre Poenitz wrote:
> > > I've just regained the ability to hit InsetExternal by updating the
> > > cache data. I suspect that other insets are missing this too.
> > >
> > > void InsetExternal::draw(PainterInfo & pi, int x, int y) const
> > > {
> > > + xo_ = x;
> > > + yo_ = y;
> > > renderer_->draw(pi, x, y);
> >
> > Strikes me as a highly dubious thing to do, but since I'm not doing any
> > coding, I suppose I don't have a say ...
>
> When you expect an inset to remember its position you have to tell it to
> remember it at some point of time.
>
> We could have a 'setPosition(x, y)' call immediately before the draw()
> call though, which does nothing in the simple insets and sets xo_, yo_
> in the more complicated once. Implementing it in InsetOld and
> MathNestInset should suffice.
>
> Better this way?
Personal feeling? Yes, although my suggestion of draw, priv_draw would result
in only one virtual function here as opposed to your two. Perhaps ;-)
As for simple: I think that even the button insets need to set this. Try
clicking on InsetExternal with things as they stand.
Angus
Re: feature request
On Wed, Dec 03, 2003 at 10:04:17PM +0100, Moritz Moeller-Herrmann wrote: > Andre Poenitz wrote: > > > On Tue, Dec 02, 2003 at 11:56:36PM +0100, Moritz Moeller-Herrmann wrote: > > >> BTW, what has happened to the footnote numbering patch? Is the latex > >> counter implementation up to the task now? > > > If you are happy with a linear numbering for the whole doc this should > > work almost out-of-the box now. > > Good to hear. Is lyx-1.4 stable enough already for a PHD with 300 pages? Not at all. [Btw whom do you expect to read a PhD thesis with 300 pages?] Andre'
Re: Inline-Mode for InsetCollapsable
On Thu, Dec 04, 2003 at 12:44:15AM +, John Levon wrote:
> On Wed, Dec 03, 2003 at 11:09:45PM +, Angus Leeming wrote:
>
> > Hi, joohn!
>
> Bah, my keyboard is dyiing :(
>
> > I've just regained the ability to hit InsetExternal by updating the
> > cache data. I suspect that other insets are missing this too.
> >
> > void InsetExternal::draw(PainterInfo & pi, int x, int y) const
> > {
> > + xo_ = x;
> > + yo_ = y;
> > renderer_->draw(pi, x, y);
>
> Strikes me as a highly dubious thing to do, but since I'm not doing any
> coding, I suppose I don't have a say ...
When you expect an inset to remember its position you have to tell it to
remember it at some point of time.
We could have a 'setPosition(x, y)' call immediately before the draw()
call though, which does nothing in the simple insets and sets xo_, yo_
in the more complicated once. Implementing it in InsetOld and
MathNestInset should suffice.
Better this way?
Andre'
Re: crash on scroll
Edwin Leuven wrote: > on opening the userguide and scrolling down with the mouse lyx > crashes Some invalidation of iterators --- André et al.'s world. How do you find the scrolling with the mouse? -- Angus
Re: crash on scroll
on opening the userguide and scrolling down with the mouse lyx crashes > Some invalidation of iterators --- André et al.'s world. yep How do you find the scrolling with the mouse? can't scroll very much because it crashes lyx what changed? it seems as if it's more controlled ie in 1.3.3 there's more flicker and selecting while dragging down the mouse is too fast... (cvs is also slower however...) regards, ed.
insert collapsable -> crash
most recent cvs. Regards, Jürgen.
Re: crash on scroll
Edwin Leuven wrote: >> How do you find the scrolling with the mouse? > can't scroll very much because it crashes lyx > what changed? it seems as if it's more controlled ie in 1.3.3 > there's more flicker and selecting while dragging down the mouse is > too fast... I tried to make it controllable... Also, you don't need to move the mouse continually anymore to scroll. Just move it beneath the work area, stop and watch. > (cvs is also slower however...) Well ideally the scrolling speed should be proportional to the distance of the mouse below the bottom of the work area. In practice this is a refinement that needs some work. -- Angus
Re: The current char style UI
On Thu, Dec 04, 2003 at 11:43:16AM +0100, Helge Hafting wrote: > Andre Poenitz wrote: > > >>I can't even unapply a change of some text to bold in mathed without > >>running round the houses. > > > > > >What's wrong with ? > > > > People don't think of text as formulas. In the text, I expect > backspace to erase the character (or other object) to the left of the > cursor. And what do you expect if the cursor is at the beginning of some chunk of text in a box? 'Nothing' is certainly a valid option, but 'remove the thing before', i.e. the box itself, is another sensible choice. Don't you think so? > Now we're getting an exception if there happens to be a style change > where the cursor is. This will surprise users, some of which don't use > math so they haven't seen it there either. There'll be complaints > like: "I was removing some text (holding down backspace) and suddenly > the formatting (emphasis/bold/font) screwed up?" When you reach the beginning of the format change, the format change will be removed. Yes. Well, you get what you ordered. Same argument as John's when he opposed equivalent changes in mathed. Nobody, not a single person! complained about this since 1.3.0 is out. I am really tempted to call this argument 'FUD'. Btw note that this 'magic key to remove formatting' does not have to be backspace. Could be any key you want. Heck, you could even deactivate it if having that feature makes you sick. It just happens to work like that in mathed for six years or so... > Also, inability to select half of the emphasized text plus some text > outside the emphasis will be a problem. You are probably right that > people rarely apply styles this way, but I often enough mark text this > way in order to _remove_ it. It'll be interesting to see if that > becomes a problem with the box-oriented approach. As I said, 'non balanced selection' is implementable, but I don't see a point in implementing it before a real user actually complains. > I tried compiling lyx in order to test this, unfortunately the > resulting binary won't let me write anything with the keyboard, only > move around & paste. Huh? 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...)
Re: The current char style UI
On Wed, Dec 03, 2003 at 07:06:18PM +, John Levon wrote: > On Wed, Dec 03, 2003 at 06:56:19PM +0100, Andre Poenitz wrote: > > > > > If you really want, you can add two or three generic items (undo inner > > > > level, split inner box, merge adjacent boxes) but I doubt anybody ever > > > > will use them as soon as he discovered the keyboaerd short cuts. > > > > > > If I saw such menu entries I would be completely lost. > > > > Hm. Tooltip 'Read section x.y in the Userguide if you are lost'. > > Tooltips on menus are horrible. Furthermore, forcing the user into the > manuals for such a simple basic editing is horrible. > > > > I'd just think "what the fuck?". It's thoroughly bizarre and if you > > > can't see that there's really no point in trying to talk to you about > > > this :( > > > > You seem to assume that any UI different from OO/Word is non-intuitive, > > misleading etc. > > Sorry, I'm not. What I am saying is that when we do differ from what > people are used to, we'd better > > a) have some really really good reasons for it I think we have this reason as we promise structured editing and deliver it. > b) better be really really careful to make it discoverable and easy to >learn Having it in the menu would make it discoverable, describing it in the UserGuide is sufficient in my opinion. > > So what are menus good for in general? To find rarely used stuff I > > suppose. > > Partially. The primary purpose of menus, though, is discoverability. Good. So the split box/remove box should go to Edit. > > > And if I am unsure about an item I just try it out and if the > > result puzzles me I'll look it up in the man page. > > You should always try to imagine users as "intelligent, but very busy". > If I have to constantly refer to the docs for basic editing operations, Users have do that 'discovery' exactly once. _Using_ the feature is, after all, really simple. > I'll just go use something else where the method is transparent and > clear. The method is transparent and clear. It just happens not to coincide with the one used in OOo and Word. Using the method is simple. So what's your main point now? That the user won't use LyX because he won't find out how a certain simple feature works even if it is described in detail in the UserGuide? To be honest, I don't care too much for such users. But I doubt there are any in this category at all. > > > Please look up what "direct manipulation" means. > > > > Where? Dictionary? > > http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=200 > > (Actually by that rather strict definition, neither way is, but > certainly mine is a lot closer) Yes, box removing by is 'direct manipulation' according to this definition. What's wrong with this approach (especially if there's a corresponding entry in the Edit menu?) Andre'
Re: The current char style UI
Andre Poenitz wrote: I can't even unapply a change of some text to bold in mathed without running round the houses. What's wrong with ? People don't think of text as formulas. In the text, I expect backspace to erase the character (or other object) to the left of the cursor. It has always been like that, in lyx, other editors, and other places were text are edited, such as bash prompt, form fields, and so on. Now we're getting an exception if there happens to be a style change where the cursor is. This will surprise users, some of which don't use math so they haven't seen it there either. There'll be complaints like: "I was removing some text (holding down backspace) and suddenly the formatting (emphasis/bold/font) screwed up?" Also, inability to select half of the emphasized text plus some text outside the emphasis will be a problem. You are probably right that people rarely apply styles this way, but I often enough mark text this way in order to _remove_ it. It'll be interesting to see if that becomes a problem with the box-oriented approach. I tried compiling lyx in order to test this, unfortunately the resulting binary won't let me write anything with the keyboard, only move around & paste. Helge Hafting
crash on scroll
on opening the userguide and scrolling down with the mouse lyx crashes opening the userguide and clicking on 'navigate' in the menu has the same effect Assertion triggered in T& boost::optional::operator*() [with T = int] by failing check "m_initialized" in file ../../lyx-devel/boost/boost/optional.hpp:193 Program received signal SIGABRT, Aborted. [Switching to Thread 1084795456 (LWP 486)] 0xe002 in ?? () (gdb) bt #0 0xe002 in ?? () #1 0x42028c55 in abort () from /lib/tls/libc.so.6 #2 0x082ed3d3 in lyx::support::abort() () at ../../../lyx-devel/src/support/abort.C:19 #3 0x0809b9b6 in boost::assertion_failed(char const*, char const*, char const*, long) (expr=0x833ba40 "m_initialized", function=0x833b740 "T& boost::optional::operator*() [with T = int]", file=0x833b9e0 "../../lyx-devel/boost/boost/optional.hpp", line=193) at ../../lyx-devel/src/boost.C:56 #4 0x080d2ae4 in ParConstIterator::operator++() (this=0xbfffe554) at optional.hpp:193 #5 0x0811f07a in ownerPar(Buffer const&, InsetOld const*) ([EMAIL PROTECTED], inset=0x85f3380) at ../../lyx-devel/src/paragraph_funcs.C:589 #6 0x081bddbf in InsetNewline::draw(PainterInfo&, int, int) const ( this=0x85f3380, [EMAIL PROTECTED], x=224, y=78) at ../../../lyx-devel/src/insets/insetnewline.C:90 #7 0x08124b33 in (anonymous namespace)::RowPainter::paintInset(int) ( this=0xbfffe834, pos=137911848) at ../../lyx-devel/src/rowpainter.C:198 #8 0x0812537a in (anonymous namespace)::RowPainter::paintFromPos(int&) ( this=0xbfffe834, [EMAIL PROTECTED]) at ../../lyx-devel/src/rowpainter.C:350 #9 0x081271ee in (anonymous namespace)::RowPaint
