Re: CRASH: upon loading UserGuide.
On Tue, Sep 02, 2003 at 01:19:58AM +0200, Lars Gullik Bj?nnes wrote: > Or begin reverting patches until it works again... We're way beyond that point. You had your chance to complain a long time ago regards, john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: CRASH: upon loading UserGuide.
On Tue, Sep 02, 2003 at 01:19:58AM +0200, Lars Gullik Bj?nnes wrote: > Or begin reverting patches until it works again... btw, this is just one tiny part if you haven't tried using CVS lyx recently ... 40-50 regressions at least regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: CRASH: upon loading UserGuide.
On Tue, Sep 02, 2003 at 12:50:49AM +0200, Lars Gullik Bjønnes wrote: > > Current CVS is crashing on loading the UserGuide... not good. Works for me. On Linux, Solaris and Cygwin. -- 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: Why lyx2lyx? why?
Lars Gullik Bjønnes wrote: > Now come to think of it... not unlikely at all. > > Can you try this patch and see if it makes a difference? > Indeed! That fixes the problem! With Alfredo's last test patch things look pretty good. Thanks, Garst
Re: CRASH: upon loading UserGuide.
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Sep 02, 2003 at 01:19:58AM +0200, Lars Gullik Bj?nnes wrote: > >> Or begin reverting patches until it works again... > | btw, this is just one tiny part if you haven't tried using CVS lyx | recently ... 40-50 regressions at least And not being able to load documents are the worst regressions of them all, and it is quite new. (less than a week ( or two)) -- Lgb
Re: CRASH: upon loading UserGuide.
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Tue, Sep 02, 2003 at 12:50:49AM +0200, Lars Gullik Bjønnes wrote: >> >> Current CVS is crashing on loading the UserGuide... not good. > | Works for me. > | On Linux, Solaris and Cygwin. I bet I have some missing fonts. _but_ LyX should not crash because of that. and if we really require those fonts we must have tham as part of our dist/install/cvs. -- Lgb
Re: CRASH: upon loading UserGuide.
On Tue, Sep 02, 2003 at 09:34:04AM +0200, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On Tue, Sep 02, 2003 at 01:19:58AM +0200, Lars Gullik Bj?nnes wrote: > > > >> Or begin reverting patches until it works again... > > > | btw, this is just one tiny part if you haven't tried using CVS lyx > | recently ... 40-50 regressions at least > > And not being able to load documents are the worst regressions of them > all, and it is quite new. (less than a week ( or two)) I am running the latest CVS and not seeing this problem. Or maybe it's unique to the lyx-qt version? ---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: CRASH: upon loading UserGuide.
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | On Tue, Sep 02, 2003 at 09:34:04AM +0200, Lars Gullik Bjønnes wrote: >> John Levon <[EMAIL PROTECTED]> writes: >> >> | On Tue, Sep 02, 2003 at 01:19:58AM +0200, Lars Gullik Bj?nnes wrote: >> > >> >> Or begin reverting patches until it works again... >> > >> | btw, this is just one tiny part if you haven't tried using CVS lyx >> | recently ... 40-50 regressions at least >> >> And not being able to load documents are the worst regressions of them >> all, and it is quite new. (less than a week ( or two)) > | I am running the latest CVS and not seeing this problem. Or maybe it's | unique to the lyx-qt version? This is with xforms. -- Lgb
Re: crash with previews
Alfredo Braunstein wrote: > Alfredo Braunstein wrote: > >> Open the userguide with previews activated and wait a little -> crash. > > This solves it. Ok to commit? Well? Can someone confirm the crash at least? Regards, Alfredo
Re: [patch] Fix some zlib issues.
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > | | This patch should take care of most of the zlib issues. >> | | But I seems to have stumbled upon some other problems, espacially with | | insertion of lyx files. Has that been working of a very long time? >> | | Anyway...the patch... > | And this is an update where a temporary file is used for lyx2lyx. Stats for final patch: po/POTFILES.in|1 src/BufferView.C | 41 +- src/buffer.C | 108 +- src/buffer.h | 10 +++- src/frontends/Alert.C | 69 +-- 5 files changed, 103 insertions(+), 126 deletions(-) -- Lgb
Re: crash with previews
-BEGIN PGP SIGNED MESSAGE- On Dienstag, 2. September 2003 09:54, Alfredo Braunstein wrote: > Alfredo Braunstein wrote: > > Alfredo Braunstein wrote: > >> Open the userguide with previews activated and wait a little -> crash. > > > > This solves it. Ok to commit? > > Well? > > Can someone confirm the crash at least? The xforms-version crashes on the userguide here too. But only if loading the english version. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP1RU4rewfbDGmeqhAQF4cAP8CrJUJz3Ejhu8jM2IiOXu5BH+BAWphIcY eg0AtYNdy3Sw5oaBSWLnPHTKl9HS5+bFnSpRy7meXRemseD452PVjhZ7J8sOOANO OhXntXm3f0sAT4G8Rw4/UOmRFoewK5x6dLuKgUJDktkc9TE8RkvbzpXtp3nU+6Lj fQNhL7IszJo= =hVVV -END PGP SIGNATURE-
Re: CRASH: upon loading UserGuide.
On Tue, Sep 02, 2003 at 09:34:04AM +0200, Lars Gullik Bjønnes spake thusly: > > John Levon <[EMAIL PROTECTED]> writes: > > | On Tue, Sep 02, 2003 at 01:19:58AM +0200, Lars Gullik Bj?nnes wrote: > > > >> Or begin reverting patches until it works again... > > > | btw, this is just one tiny part if you haven't tried using CVS lyx > | recently ... 40-50 regressions at least > > And not being able to load documents are the worst regressions of them > all, and it is quite new. (less than a week ( or two)) > > -- > Lgb This one is related to bformat usage in formulamacro.C:127. - Martin pgp0.pgp Description: PGP signature
Re: CRASH: upon loading UserGuide.
Martin Vermeer <[EMAIL PROTECTED]> writes: | On Tue, Sep 02, 2003 at 09:34:04AM +0200, Lars Gullik Bjønnes spake thusly: >> >> John Levon <[EMAIL PROTECTED]> writes: >> >> | On Tue, Sep 02, 2003 at 01:19:58AM +0200, Lars Gullik Bj?nnes wrote: >> > >> >> Or begin reverting patches until it works again... >> > >> | btw, this is just one tiny part if you haven't tried using CVS lyx >> | recently ... 40-50 regressions at least >> >> And not being able to load documents are the worst regressions of them >> all, and it is quite new. (less than a week ( or two)) >> >> -- >> Lgb > | This one is related to bformat usage in formulamacro.C:127. Are you saying that getInsetName() is the culprit? -- Lgb
Re: gtk+ patch 2003-9-2
Huang Ying <[EMAIL PROTECTED]> writes: | sorry for my late, I hope I can work harder next time. No worries. I am working on integrating your patch now. -- Lgb
Re: CRASH: upon loading UserGuide.
Lars Gullik Bjønnes wrote:
>
> This is with xforms.
>
> --
> Lgb
I'm not seeing it with Alfredo's patch:
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.424
diff -u -p -u -r1.424 BufferView_pimpl.C
--- BufferView_pimpl.C 28 Aug 2003 07:41:10 - 1.424
+++ BufferView_pimpl.C 1 Sep 2003 20:12:46 -
@@ -656,7 +656,6 @@ void BufferView::Pimpl::update()
if (bv_->getLyXText()) {
// check needed to survive LyX startup
bv_->getLyXText()->redoCursor();
- fitCursor();
}
screen().redraw(*bv_);
}
and your zlib-2.diff applied.
(also with xforms, preview not enabled).
Garst
Re: [PATCH] typo
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Juergen Spitzmueller wrote: >> can I apply this to 1.3 and 1.4? Juergen> If no one objects until tomorrow morning, I'll apply it (it's Juergen> really obvious). I see you did it, it was indeed obvious... JMarc
Re: gtk+ patch 2003-9-2
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > | | Huang Ying <[EMAIL PROTECTED]> writes: >> | | | sorry for my late, I hope I can work harder next time. >> | | No worries. >> | | I am working on integrating your patch now. > | Thisis the resulting patch, it should be identical to yours. I will only make sure that this does not break any of the regular compile before committing. -- Lgb
Re: CRASH: upon loading UserGuide.
Lars Gullik Bjønnes wrote:
> Are you saying that getInsetName() is the culprit?
return bformat(_(" Macro: %s: "), getInsetName());
Unrelated: shouldn't the %s be a %1$s to avoid the non-boost::format assert?
Alfredo
Re: CRASH: upon loading UserGuide.
On Tue, Sep 02, 2003 at 11:05:39AM +0200, Lars Gullik Bjønnes spake thusly:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Tue, Sep 02, 2003 at 09:34:04AM +0200, Lars Gullik Bjønnes spake thusly:
> >>
> >> John Levon <[EMAIL PROTECTED]> writes:
> >>
> >> | On Tue, Sep 02, 2003 at 01:19:58AM +0200, Lars Gullik Bj?nnes wrote:
> >> >
> >> >> Or begin reverting patches until it works again...
> >> >
> >> | btw, this is just one tiny part if you haven't tried using CVS lyx
> >> | recently ... 40-50 regressions at least
> >>
> >> And not being able to load documents are the worst regressions of them
> >> all, and it is quite new. (less than a week ( or two))
> >>
> >> --
> >>Lgb
> >
> | This one is related to bformat usage in formulamacro.C:127.
>
> Are you saying that getInsetName() is the culprit?
No, but the following patch makes the user guide load for me:
--- formulamacro.C 28 Aug 2003 07:41:31 - 1.134
+++ formulamacro.C 2 Sep 2003 10:10:28 -
@@ -124,7 +124,7 @@ void InsetFormulaMacro::read(std::istrea
string InsetFormulaMacro::prefix() const
{
- return bformat(_(" Macro: %s: "), getInsetName());
+ return bformat(_(" Macro: %1$s: "), getInsetName());
}
> --
> Lgb
>
- Martin
pgp0.pgp
Description: PGP signature
Re: Inset::display() ?
John Levon wrote: > On Mon, Sep 01, 2003 at 03:27:40PM -0300, Garst R. Reese wrote: > >> > It's not past tense: >> yes it is. > > No it's not. > >> > if (box.contained(x, y)) >> > >> > if position x,y is contained in box >> > >> Then how would say: >> if position x,y was contained in box > > a) you wouldn't > b) "was" is past tense, "is" is not Actually, it's grammatically incorect (read poor use of the subjunctive) and should be if position x,y were contained in box So nuh! -- Angus
Re: CRASH: upon loading UserGuide.
On Mon, Sep 01, 2003 at 05:38:56PM -0700, Kayvan A. Sylvan spake thusly: > > On Tue, Sep 02, 2003 at 12:50:49AM +0200, Lars Gullik Bjønnes wrote: > > > > Current CVS is crashing on loading the UserGuide... not good. > > Works for me. > > On Linux, Solaris and Cygwin. Of course... if you use the non-included boost. See Alfredo's post. > -- > 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) > - Martin pgp0.pgp Description: PGP signature
Re: CRASH: upon loading UserGuide.
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Are you saying that getInsetName() is the culprit?
>
| return bformat(_(" Macro: %s: "), getInsetName());
>
| Unrelated: shouldn't the %s be a %1$s to avoid the non-boost::format assert?
Yes but %1 should be allowed... so this shows a bug in bformat.
but let's change this to %1$s.
--
Lgb
Re: Inset::display() ?
On Tue, Sep 02, 2003 at 11:14:34AM +0100, Angus Leeming spake thusly: > John Levon wrote: > > > On Mon, Sep 01, 2003 at 03:27:40PM -0300, Garst R. Reese wrote: > > > >> > It's not past tense: > >> yes it is. > > > > No it's not. > > > >> > if (box.contained(x, y)) > >> > > >> > if position x,y is contained in box > >> > > >> Then how would say: > >> if position x,y was contained in box > > > > a) you wouldn't > > b) "was" is past tense, "is" is not > > Actually, it's grammatically incorect (read poor use of the > subjunctive) and should be > if position x,y were contained in box > So nuh! > > -- > Angus So, could you native speakers come up with a consensus proposal what to call it? I would make it box.inside(x,y), but what do I know. - Martin pgp0.pgp Description: PGP signature
Re: CRASH: upon loading UserGuide.
Lars Gullik Bjønnes wrote:
> | return bformat(_(" Macro: %s: "), getInsetName());
> Yes but %1 should be allowed... so this shows a bug in bformat.
> but let's change this to %1$s.
Also %s should. And I guess you are using boost::format, so your crash is
somewhere else, isn't it?
Alfredo
Re: Inset::display() ?
Martin Vermeer wrote: >> Actually, it's grammatically incorect (read poor use of the >> subjunctive) and should be >> if position x,y were contained in box >> So nuh! >> > So, could you native speakers come up with a consensus proposal what > to call it? I would make it box.inside(x,y), but what do I know. Aug! Don't spoil our fun ;-) Call it "contains". Finland's converted to the euro hasn't it? In that case, just my 2c worth ;-) -- Angus
Re: Inset::display() ?
Angus Leeming wrote: >> a) you wouldn't >> b) "was" is past tense, "is" is not > > Actually, it's grammatically incorect (read poor use of the > subjunctive) and should be > if position x,y were contained in box > So nuh! We should definitively have both the indicative and subjuntive version of the function, to maintain grammatically correct code! Dead to illiterate programming! Alfredo
Re: CRASH: upon loading UserGuide.
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> | return bformat(_(" Macro: %s: "), getInsetName());
>> Yes but %1 should be allowed... so this shows a bug in bformat.
>> but let's change this to %1$s.
>
| Also %s should. And I guess you are using boost::format, so your crash is
| somewhere else, isn't it?
Yes I should be using boost:.format, (and I ment %s not %1)
But the change is good anyway.
--
Lgb
Re: Inset::display() ?
On wtorek 02 wrzesień 2003 06:46 am, Alfredo Braunstein wrote:
> Angus Leeming wrote:
> >> a) you wouldn't
> >> b) "was" is past tense, "is" is not
> >
> > Actually, it's grammatically incorect (read poor use of the
> > subjunctive) and should be
> > if position x,y were contained in box
> > So nuh!
>
> We should definitively have both the indicative and subjuntive version of
> the function, to maintain grammatically correct code! Dead to illiterate
> programming!
I think that this discussion tries to differentiate between "a box contains
the point" vs. "a point is contained by the box". The difference is whether
in "object.action(target)" one thinks from target to the object (RTL) or from
object to the target (LTR). As far as grammatics are concerned, methinks that
both are equally proper, at least in the lame street language one learns on
mailing lists ;D
Personally, I would look for "contains" first. A quick grep of my own sources
(aboslutely LyX-unrelated) reveals that there are a couple of "contained" in
the comments, and two "contains" in the class declarations. But, it
definitely won't hurt if we have
{
...
bool contained(whatever) const;
inline bool contains(whatever) const { return contained(whatever); }
...
}
Alternatively, intersects() and intersectedBy() would be proper in
mathematical sense.
Cheers, Kuba Ober
[BUG] cursor out of sync with position in view
When scrolling down with PgDown, the cursor moves along, but if you stop and press then the page switches to a completely different place (probably one page up or down from what was viewed). -- Lgb
[bug] empty lines presend under inset only paragraphs.
what subject says. rather annoying. -- Lgb
Re: Inset::display() ?
On Mon, Sep 01, 2003 at 03:05:57PM +0100, Angus Leeming spake thusly:
> >
> > First try...
Second try.
...
> * insetbibtex.C:
> + Box b(
> + center_indent_,
> + center_indent_ + dim.wid,
> + -dim.asc,
> + dim.des
> + );
> You wan't win any friends for this sort of fancy indentation.
As I value your friendship, advise me :-/
...
> --
> Angus
>
- Martin
Index: box.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/box.C,v
retrieving revision 1.8
diff -u -p -r1.8 box.C
--- box.C 23 Aug 2003 00:16:06 - 1.8
+++ box.C 2 Sep 2003 14:05:45 -
@@ -23,6 +23,9 @@ Box::Box(int x1_, int x2_, int y1_, int
x1(x1_), x2(x2_), y1(y1_), y2(y2_)
{}
+Box::Box() :
+ x1(0), x2(0), y1(0), y2(0)
+{}
bool Box::contained(int x, int y)
{
Index: box.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/box.h,v
retrieving revision 1.8
diff -u -p -r1.8 box.h
--- box.h 23 Aug 2003 00:16:06 - 1.8
+++ box.h 2 Sep 2003 14:05:45 -
@@ -30,7 +30,10 @@ struct Box {
/// Initialise the member variables.
Box(int x1_, int x2_, int y1_, int y2_);
+ /// Shorter version:
+ Box();
+
/**
* Returns true if the given co-ordinates are within
* the box. Check is exclusive (point on a border
Index: insets/insetbibtex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetbibtex.C,v
retrieving revision 1.21
diff -u -p -r1.21 insetbibtex.C
--- insets/insetbibtex.C28 Aug 2003 07:41:28 - 1.21
+++ insets/insetbibtex.C2 Sep 2003 14:05:45 -
@@ -57,7 +57,14 @@ std::auto_ptr InsetBibtex::cl
void InsetBibtex::metrics(MetricsInfo & mi, Dimension & dim) const
{
InsetCommand::metrics(mi, dim);
- center_indent_ = (mi.base.textwidth - dim.wid) / 2;
+ int center_indent_ = (mi.base.textwidth - dim.wid) / 2;
+ Box b(
+ center_indent_,
+ center_indent_ + dim.wid,
+ -dim.asc,
+ dim.des
+ );
+ setButtonBox(b);
dim.wid = mi.base.textwidth;
dim_ = dim;
}
@@ -65,7 +72,7 @@ void InsetBibtex::metrics(MetricsInfo &
void InsetBibtex::draw(PainterInfo & pi, int x, int y) const
{
- InsetCommand::draw(pi, x + center_indent_, y);
+ InsetCommand::draw(pi, x + buttonBox().x1, y);
}
@@ -73,8 +80,9 @@ dispatch_result InsetBibtex::localDispat
{
switch (cmd.action) {
- case LFUN_INSET_EDIT:
- InsetCommandMailer("bibtex", *this).showDialog(cmd.view());
+ case LFUN_MOUSE_RELEASE:
+ if (buttonBox().contained(cmd.x, cmd.y))
+ InsetCommandMailer("bibtex", *this).showDialog(cmd.view());
return DISPATCHED;
case LFUN_INSET_MODIFY: {
Index: insets/insetbibtex.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetbibtex.h,v
retrieving revision 1.20
diff -u -p -r1.20 insetbibtex.h
--- insets/insetbibtex.h28 Aug 2003 07:41:28 - 1.20
+++ insets/insetbibtex.h2 Sep 2003 14:05:45 -
@@ -50,9 +50,6 @@ public:
bool addDatabase(string const &);
///
bool delDatabase(string const &);
-private:
- ///
- mutable unsigned int center_indent_;
};
#endif // INSET_BIBTEX_H
Index: insets/insetcommand.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcommand.h,v
retrieving revision 1.69
diff -u -p -r1.69 insetcommand.h
--- insets/insetcommand.h 28 Aug 2003 07:41:29 - 1.69
+++ insets/insetcommand.h 2 Sep 2003 14:05:45 -
@@ -18,6 +18,7 @@
#include "insetcommandparams.h"
#include "renderers.h"
#include "mailinset.h"
+#include "box.h"
// Created by Alejandro 970222
/** Used to insert a LaTeX command automatically
@@ -66,7 +67,11 @@ public:
void setContents(string const & c) { p_.setContents(c); }
///
string const & getOptions() const { return p_.getOptions(); }
-
+ ///
+ Box buttonBox() const { return button_box_; }
+ ///
+ void setButtonBox(Box b) const { button_box_ = b; }
+
protected:
///
string const getCommand() const { return p_.getCommand(); }
@@ -88,6 +93,7 @@ private:
InsetCommandParams p_;
mutable bool set_label_;
mutable ButtonRenderer button_;
+ mutable Box button_box_;
};
Index: insets/insetfloatlist.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetfloatlist.C,v
retrieving revision 1.39
diff -u -p -r1.39 inset
Re: gtk+ patch 2003-9-2
On Tue, Sep 02, 2003 at 10:00:18AM +0800, Huang Ying wrote: > sorry for my late, I hope I can work harder next time. Lars applied this. But it won't compile : In file included from lyx_gui.C:39: GtkmmX.h: In function `Window getRootWindow()': GtkmmX.h:37: no class template named `Display' in `Gdk' regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [bug] empty lines presend under inset only paragraphs.
On Tue, Sep 02, 2003 at 04:01:32PM +0200, Lars Gullik Bj?nnes wrote: > what subject says. If you can work out how to fix rowBreakPoint() without causing a more serious regression, be my guest... but there are much more important bugs around regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Inset::display() ?
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Index: box.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/box.C,v
| retrieving revision 1.8
| diff -u -p -r1.8 box.C
| --- box.C 23 Aug 2003 00:16:06 - 1.8
| +++ box.C 2 Sep 2003 14:05:45 -
| @@ -23,6 +23,9 @@ Box::Box(int x1_, int x2_, int y1_, int
| x1(x1_), x2(x2_), y1(y1_), y2(y2_)
| {}
|
| +Box::Box() :
| + x1(0), x2(0), y1(0), y2(0)
| +{}
Box::Box()
: x1(0), x2(0), y1(0), y2(0)
{}
| bool Box::contained(int x, int y)
Hmm... didn't you agree on "contains"?
| @@ -57,7 +57,14 @@ std::auto_ptr InsetBibtex::cl
| void InsetBibtex::metrics(MetricsInfo & mi, Dimension & dim) const
| {
| InsetCommand::metrics(mi, dim);
| - center_indent_ = (mi.base.textwidth - dim.wid) / 2;
| + int center_indent_ = (mi.base.textwidth - dim.wid) / 2;
| + Box b(
| + center_indent_,
| + center_indent_ + dim.wid,
| + -dim.asc,
| + dim.des
| + );
Hmmm...
Box b(center_indent_, center_indent_ + dim.wid,
-dim.asc, dim.des);
unless all can go on one line.
| Index: insets/insetfloatlist.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetfloatlist.C,v
| retrieving revision 1.39
| diff -u -p -r1.39 insetfloatlist.C
| --- insets/insetfloatlist.C 28 Aug 2003 07:41:29 - 1.39
| +++ insets/insetfloatlist.C 2 Sep 2003 14:05:45 -
| @@ -101,7 +101,15 @@ void InsetFloatList::read(Buffer const &
| void InsetFloatList::metrics(MetricsInfo & mi, Dimension & dim) const
| {
| InsetCommand::metrics(mi, dim);
| - center_indent_ = (mi.base.textwidth - dim.wid) / 2;
| + int center_indent_ = (mi.base.textwidth - dim.wid) / 2;
| +Box b(
| + center_indent_,
| + center_indent_ + dim.wid,
| + -dim.asc,
| + dim.des
| + );
same as above
| dispatch_result InsetFloatList::localDispatch(FuncRequest const & cmd)
| {
| switch (cmd.action) {
| - case LFUN_INSET_EDIT:
| - InsetCommandMailer("toc", *this).showDialog(cmd.view());
| + case LFUN_MOUSE_RELEASE:
| + if (buttonBox().contained(cmd.x, cmd.y))
| + InsetCommandMailer("toc",
| *this).showDialog(cmd.view());
I am not sure I agree with these changes... how can I know do stuff
from lyxserver or from cmdline?
| @@ -535,10 +536,19 @@ void InsetInclude::metrics(MetricsInfo &
| }
| button_.metrics(mi, dim);
| }
| + int center_indent_;
| if (params_.flag == INPUT)
| center_indent_ = 0;
| else
| center_indent_ = (mi.base.textwidth - dim.wid) / 2;
I wonder...
int center_indent_ = (params_.flag == INPUT ? 0 :
(mi.base.textwidth - dim.wid) / 2);
alt:
int center_indent_ = 0;
if (params_.flag != INPUT)
center_indent_ = (mi.base.textwidth - dim.wid) / 2;
but why all these variables ending with '_'?
IMHO that should be reserved for private class variables, or at least
for class variables in general.
| Index: insets/insetinclude.h
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetinclude.h,v
| retrieving revision 1.79
| diff -u -p -r1.79 insetinclude.h
| --- insets/insetinclude.h 28 Aug 2003 07:41:29 - 1.79
| +++ insets/insetinclude.h 2 Sep 2003 14:05:45 -
| @@ -14,6 +14,7 @@
|
| #include "insetcommand.h"
| #include "dimension.h"
| +#include "box.h"
don't you get this from insetcommand.h?
--
Lgb
Re: Inset::display() ?
Martin Vermeer wrote:
> As I value your friendship, advise me :-/
See Lars' comments.
Lars Gullik Bjønnes wrote:
> | dispatch_result InsetFloatList::localDispatch(FuncRequest const &
> | cmd)
> | {
> | switch (cmd.action) {
> | - case LFUN_INSET_EDIT:
> | - InsetCommandMailer("toc", *this).showDialog(cmd.view());
> | + case LFUN_MOUSE_RELEASE:
> | + if (buttonBox().contained(cmd.x, cmd.y))
> | + InsetCommandMailer("toc",
> | *this).showDialog(cmd.view());
>
> I am not sure I agree with these changes... how can I know do stuff
> from lyxserver or from cmdline?
You would invoke a new LFUN_INSET_SHOW_DIALOG. The code above should
be:
switch (cmd.action) {
- case LFUN_INSET_EDIT:
- InsetCommandMailer("toc", *this).showDialog(cmd.view());
+ case LFUN_INSET_SHOW_DIALOG:
+ case LFUN_MOUSE_RELEASE:
+ if (buttonBox().contained(cmd.x, cmd.y))
+ InsetCommandMailer("toc",
*this).showDialog(cmd.view());
Ie, it's up to the inset to decide what to do on receipt of an LFUN.
In this particular case, clicking on the button will have the same
effect as an outside request that the dialog be opened.
I think that Martin should now add the LFUN.
--
Angus
Re: gtk+ patch 2003-9-2
John Levon wrote: > Lars applied this. But it won't compile It does here. http://home.t-online.de/home/juergen.sp/lyx-gtk.png Looks good. Some comments from a first view: - the main window width can not be made smaller than 800 pixels. Is this intentional? - All toolbars are shown, no matter what I have chosen in stdtoolbars.ui - I get a crash as soon as I try to open one of the gtk dialogs (about, label): (lyx:13672): libglade-WARNING **: could not find glade file '' the file dialog works, though. Thanks, Juergen.
Re: gtk+ patch 2003-9-2
On Tue, Sep 02, 2003 at 05:28:12PM +0200, Juergen Spitzmueller wrote: > > Lars applied this. But it won't compile > > It does here. Sigh. So there is some exact version of the libraries I need. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: gtk+ patch 2003-9-2
John Levon wrote: > Sigh. So there is some exact version of the libraries I need. I have compiled the newest available versions of the libraries (I had to add a workaround to get gtkmm-2 compiled with gcc-3.3). This is the --version, if that helps: Built on Sep 2 2003, 17:03:41 Configuration Host type: i686-pc-linux-gnu Special build flags:warnings assertions use-aspell xforms-image-loader compression C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (3.3) C++ Compiler flags: -g -O -fno-exceptions -W -Wall Linker flags: libgtkmm version: 2.2.3 libglademm version: 2.0.1 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx-cvs Regards, Juergen.
Re: Inset::display() ?
On Tue, Sep 02, 2003 at 03:39:49PM +0100, Angus Leeming spake thusly:
> Martin Vermeer wrote:
> You would invoke a new LFUN_INSET_SHOW_DIALOG. The code above should
> be:
>
> switch (cmd.action) {
> - case LFUN_INSET_EDIT:
> - InsetCommandMailer("toc", *this).showDialog(cmd.view());
> + case LFUN_INSET_SHOW_DIALOG:
> + case LFUN_MOUSE_RELEASE:
> + if (buttonBox().contained(cmd.x, cmd.y))
> + InsetCommandMailer("toc",
>*this).showDialog(cmd.view());
>
> Ie, it's up to the inset to decide what to do on receipt of an LFUN.
> In this particular case, clicking on the button will have the same
> effect as an outside request that the dialog be opened.
>
> I think that Martin should now add the LFUN.
OK... the instructions in lfuns.h are clear enough.
But lyxfunc/getStatus ... looks mysterious to me. Does the
following look about right:
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.480
diff -u -p -r1.480 lyxfunc.C
--- lyxfunc.C 28 Aug 2003 07:41:14 - 1.480
+++ lyxfunc.C 2 Sep 2003 15:42:02 -
@@ -689,6 +689,19 @@ FuncStatus LyXFunc::getStatus(FuncReques
if (!mathcursor)
code = InsetOld::SPACE_CODE;
break;
+ case LFUN_INSET_SHOW_DIALOG: {
+ LyXText * lt = view()->getLyXText();
+ InsetOld * inset = lt->getInset();
+ disable = !inset;
+ if (!disable) {
+ code = inset->lyxCode();
+ if (!(code == InsetOld::INCLUDE_CODE
+ || code == InsetOld::BIBTEX_CODE
+ || code == InsetOld::TOC_CODE))
+ disable = true;
+ }
+ }
+ break;
default:
break;
}
I.e., the command should only be valid if we are "on" an inset of the
right type.
Untested, groping my way forward...
> --
> Angus
>
- Martin
pgp0.pgp
Description: PGP signature
Re: gtk+ patch 2003-9-2
On Tue, Sep 02, 2003 at 05:38:54PM +0200, Juergen Spitzmueller wrote: > I have compiled the newest available versions of the libraries That would have required me to build from glib upwards. Sod that :) Anyway, it's obvious the configure tests aren't strong enough. john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [BUG] cursor out of sync with position in view
Lars Gullik Bjønnes wrote: > When scrolling down with PgDown, the cursor moves along, but if you > stop and press then the page switches to a completely > different place (probably one page up or down from what was viewed). Can you check if the patch attached to http://bugzilla.lyx.org/show_bug.cgi?id=1356 solves the problem and if it is good enough for applying? Regards, Alfredo
Re: gtk+ patch 2003-9-2
Huang Ying wrote: > > Looks good. Some comments from a first view: > > - the main window width can not be made smaller than 800 pixels. Is this > > intentional? > > yes! How much do you think the minimum width is appropiate? Don't know. The qt version can be shrinked to about 80x200. I'd say 400x300 has to be possible at least (think of working with LyX and gv side by side on a 800x600 screen and think of the poor users who are still working with 640x480). I am working with 800x600 and have the kicker on the right edge, so 800 pixel width is a bit too wide for my personal use. > > - All toolbars are shown, no matter what I have chosen in stdtoolbars.ui > > I will check this to find the reason. You might also want to check which menu entries you really need. E.g. in qt, "show tooltips" does not make sense. Therefore we do not show this menu entry. I guess this is the same for gtk (the xforms "tooltips" are more or less "what's this?" texts, i.e. very verbose). > > - I get a crash as soon as I try to open one of the gtk dialogs (about, > > label): > > (lyx:13672): libglade-WARNING **: could not find glade file '' > > the file dialog works, though. > > You must install it before execute. Because the file search path problem. Ah ok. Installing solves it indeed. Regards, Juergen.
Re: Inset::display() ?
Martin Vermeer wrote:
> On Tue, Sep 02, 2003 at 03:39:49PM +0100, Angus Leeming spake thusly:
>
>> Martin Vermeer wrote:
>
>> You would invoke a new LFUN_INSET_SHOW_DIALOG. The code above should
>> be:
>>
>> switch (cmd.action) {
>> - case LFUN_INSET_EDIT:
>> - InsetCommandMailer("toc",
>> *this).showDialog(cmd.view());
>> + case LFUN_INSET_SHOW_DIALOG:
>> + case LFUN_MOUSE_RELEASE:
>> + if (buttonBox().contained(cmd.x, cmd.y))
>> + InsetCommandMailer("toc",
>>
*this).showDialog(cmd.view());
>>
>> Ie, it's up to the inset to decide what to do on receipt of an LFUN.
>> In this particular case, clicking on the button will have the same
>> effect as an outside request that the dialog be opened.
>>
>> I think that Martin should now add the LFUN.
>
> OK... the instructions in lfuns.h are clear enough.
>
> But lyxfunc/getStatus ... looks mysterious to me. Does the
> following look about right:
Sorry to be a pain, but I've just looked at the 1.4.x source. I think that
the LFUN exists already as LFUN_DIALOG_SHOW_NEXT_INSET. This LFUN is meant
to move the cursor to either
just in front of the next non-editable inset.
or
to the first position inside an editable inset.
and then open the associated dialog. However, I don't think that I got round
to writing the code (I was feeling militant ;-)
The code itself is conceptually identical to that written by Jean-Marc to
open/close the next collapsed inset from the current cursor position.
HTH,
--
Angus
Re: [Devel] [patch] more 'who we are' nonsense
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Ok. However, I think that "author" implies "significant" input. Angus> I don't think that I have contributed anything at all other Angus> than some Makefile and build infrastructure. Jean-Marc, on the Angus> other hand, has definitely been busy ;-) You mean that you do not want to take the blame for everything we broke? Come on! JMarc
Re: [Devel] [patch] more 'who we are' nonsense
On Tuesday 02 September 2003 4:32 pm, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Ok. However, I think that "author" implies "significant" input. > Angus> I don't think that I have contributed anything at all other > Angus> than some Makefile and build infrastructure. Jean-Marc, on the > Angus> other hand, has definitely been busy ;-) > > You mean that you do not want to take the blame for everything we > broke? Come on! Damn! I thought I'd be able to slip that by you, what with your holiday an' all ;-) Welcome back, A
[PATCH] .ix/y cleanup
For some time, .ix() and .iy() have been exactly the same values as .x()
and .y(). This patch is a no-functional-change cleanup. See my other
post for cursor placement issues.
OK ?
11 files changed, 31 insertions(+), 85 deletions(-)
regards
john
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.185
diff -u -p -r1.185 BufferView.C
--- BufferView.C2 Sep 2003 08:26:18 - 1.185
+++ BufferView.C2 Sep 2003 16:35:22 -
@@ -479,7 +479,7 @@ bool BufferView::lockInset(UpdatableInse
bool BufferView::fitLockedInsetCursor(int x, int y, int asc, int desc)
{
if (theLockingInset() && available()) {
- y += text->cursor.iy() + theLockingInset()->insetInInsetY();
+ y += text->cursor.y() + theLockingInset()->insetInInsetY();
if (screen().fitManualCursor(this, text, x, y, asc, desc)) {
updateScrollbar();
return true;
Index: lyxcursor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxcursor.h,v
retrieving revision 1.36
diff -u -p -r1.36 lyxcursor.h
--- lyxcursor.h 2 Sep 2003 08:26:19 - 1.36
+++ lyxcursor.h 2 Sep 2003 16:35:23 -
@@ -46,16 +46,6 @@ public:
void x(int i);
/// return the x position in pixels
int x() const;
- /// set the stored next-line position when at the end of a row
- void ix(int i);
- /**
-* Return the x position of the start of the next row, when this
-* cursor is at the end of the previous row, for insets that take
-* a full row.
-*
-* FIXME: explain why we need this ?
-*/
- int ix() const;
/// set the cached x position
void x_fix(int i);
/**
@@ -75,16 +65,7 @@ public:
void y(int i);
/// return the y position in pixels
int y() const;
- /// set the stored next-line y position when at the end of a row
- void iy(int i);
- /**
-* Return the y position of the start of the next row, when this
-* cursor is at the end of the previous row, for insets that take
-* a full row.
-*
-* FIXME: explain why we need this ? especially for y...
-*/
- int iy() const;
+
private:
/// The paragraph the cursor is in.
ParagraphList::iterator par_;
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.480
diff -u -p -r1.480 lyxfunc.C
--- lyxfunc.C 28 Aug 2003 07:41:14 - 1.480
+++ lyxfunc.C 2 Sep 2003 16:35:26 -
@@ -922,8 +922,8 @@ void LyXFunc::dispatch(FuncRequest const
if (irow != view()->text->firstRow()) {
#if 1
view()->text->setCursorFromCoordinates(
- view()->text->cursor.ix() + inset_x,
- view()->text->cursor.iy() -
+ view()->text->cursor.x() + inset_x,
+ view()->text->cursor.y() -
irow->baseline() - 1);
view()->text->cursor.x_fix(view()->text->cursor.x());
#else
@@ -940,8 +940,8 @@ void LyXFunc::dispatch(FuncRequest const
if (irow != view()->text->lastRow()) {
#if 1
view()->text->setCursorFromCoordinates(
- view()->text->cursor.ix() + inset_x,
- view()->text->cursor.iy() -
+ view()->text->cursor.x() + inset_x,
+ view()->text->cursor.y() -
irow->baseline() +
irow->height() + 1);
view()->text->cursor.x_fix(view()->text->cursor.x());
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.452
diff -u -p -r1.452 text2.C
--- text2.C 2 Sep 2003 15:44:36 - 1.452
+++ text2.C 2 Sep 2003 16:35:29 -
@@ -1352,18 +1352,12 @@ void LyXText::setCursor(LyXCursor & cur,
RowList::iterator row = getRow(pit, pos);
int y = row->y();
- RowList::iterator old_row = row;
- // if we are before the first char of this row and are still in the
- // same paragraph and there is a previous row then put the cursor on
- // the end of the previous row
- cur.iy(y + row->b
Re: Inset::display() ?
Kuba Ober wrote:
> I think that this discussion tries to differentiate between "a box
> contains the point" vs. "a point is contained by the box". The difference
> is whether in "object.action(target)" one thinks from target to the object
> (RTL) or from object to the target (LTR). As far as grammatics are
> concerned, methinks that both are equally proper, at least in the lame
> street language one learns on mailing lists ;D
You should read better:
>> > Actually, it's grammatically incorect (read poor use of the
>> > subjunctive) and should be
>> > if position x,y were contained in box
>> > So nuh!
This is all about using the subjunctive in a conditional C++ sentence!
> Personally, I would look for "contains" first. A quick grep of my own
> sources (aboslutely LyX-unrelated) reveals that there are a couple of
> "contained" in the comments, and two "contains" in the class declarations.
> But, it definitely won't hurt if we have
>
> {
> ...
> bool contained(whatever) const;
> inline bool contains(whatever) const { return contained(whatever); }
> ...
> }
If this is a joke (and I hope it is), I think I did it before you. ;-)
Regards, Alfredo
Visible cursor placement
Try pressing End in a multi-row par in current CVS. Cursor ends up on the next row, because setCursor() and friends know nothing about which row the cursor is supposed to be on. Same problem with mouse clicks (evident before a full row inset like InsetBibtex). I can't see a clean fix. Anybody ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Inset::display() ?
On Tue, Sep 02, 2003 at 05:27:21PM +, Angus Leeming spake thusly: > Martin Vermeer wrote: ... > Sorry to be a pain, but I've just looked at the 1.4.x source. I think that > the LFUN exists already as LFUN_DIALOG_SHOW_NEXT_INSET. This LFUN is meant > to move the cursor to either > just in front of the next non-editable inset. > or > to the first position inside an editable inset. > and then open the associated dialog. However, I don't think that I got round > to writing the code (I was feeling militant ;-) > > The code itself is conceptually identical to that written by Jean-Marc to > open/close the next collapsed inset from the current cursor position. Where is that code? ...and why not then implement a separate LFUN_GOTO_NEXT_INSET and get the above by putting LFUN_INSET_SHOW_DIALOG after it? One way or the other. Why do my small nice projects always develop into mega-adventures? > HTH, Not really... > -- > Angus > - Martin pgp0.pgp Description: PGP signature
Re: Inset::display() ?
On Tue, Sep 02, 2003 at 08:33:01PM +0300, Martin Vermeer wrote: > One way or the other. Why do my small nice projects always develop > into mega-adventures? Because the LyX source is in a bad way ... john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Inset::display() ?
On Tuesday 02 September 2003 5:33 pm, Martin Vermeer wrote: > On Tue, Sep 02, 2003 at 05:27:21PM +, Angus Leeming spake thusly: > > Martin Vermeer wrote: > > ... > > > Sorry to be a pain, but I've just looked at the 1.4.x source. I think > > that the LFUN exists already as LFUN_DIALOG_SHOW_NEXT_INSET. This LFUN is > > meant to move the cursor to either > > just in front of the next non-editable inset. > > or > > to the first position inside an editable inset. > > and then open the associated dialog. However, I don't think that I got > > round to writing the code (I was feeling militant ;-) > > > > The code itself is conceptually identical to that written by Jean-Marc to > > open/close the next collapsed inset from the current cursor position. > > Where is that code? > > ...and why not then implement a separate LFUN_GOTO_NEXT_INSET and get the > above by putting LFUN_INSET_SHOW_DIALOG after it? > > One way or the other. Why do my small nice projects always develop > into mega-adventures? > > > HTH, > > Not really... Don't be too down: grep INSET_TOGGLE *.C The toggle code in all it's glory is (text3.C): case LFUN_INSET_TOGGLE: bv->beforeChange(this); toggleInset(); bv->update(); bv->switchKeyMap(); break; Angus
Re: Inset::display() ?
On Tue, Sep 02, 2003 at 06:22:48PM +, Angus Leeming spake thusly: > On Tuesday 02 September 2003 5:33 pm, Martin Vermeer wrote: > > On Tue, Sep 02, 2003 at 05:27:21PM +, Angus Leeming spake thusly: > > > Martin Vermeer wrote: > > > > ... > > > > > Sorry to be a pain, but I've just looked at the 1.4.x source. I think > > > that the LFUN exists already as LFUN_DIALOG_SHOW_NEXT_INSET. This LFUN is > > > meant to move the cursor to either > > > just in front of the next non-editable inset. > > > or > > > to the first position inside an editable inset. > > > and then open the associated dialog. However, I don't think that I got > > > round to writing the code (I was feeling militant ;-) > > > > > > The code itself is conceptually identical to that written by Jean-Marc to > > > open/close the next collapsed inset from the current cursor position. > > > > Where is that code? ... > Don't be too down: > grep INSET_TOGGLE *.C > > The toggle code in all it's glory is (text3.C): >case LFUN_INSET_TOGGLE: > bv->beforeChange(this); > toggleInset(); > bv->update(); > bv->switchKeyMap(); > break; > > Angus ...but am I right in seeing that this code doesn't actually move the cursor? I.e., contrary to your description above? No, this doesn't look very impossible. - Martin pgp0.pgp Description: PGP signature
Re: Inset::display() ?
On Tuesday 02 September 2003 5:56 pm, Martin Vermeer wrote:
> > The toggle code in all it's glory is (text3.C):
> >case LFUN_INSET_TOGGLE:
> > bv->beforeChange(this);
> > toggleInset();
> > bv->update();
> > bv->switchKeyMap();
> > break;
> >
> > Angus
>
> ...but am I right in seeing that this code doesn't actually move the
> cursor? I.e., contrary to your description above?
No, it moves the cursor. See below.
Perhaps you might split this into two and create LFUN_INSET_GOTO_NEXT or some
such? If you get adventurous, you might allow it to take an optional argument
so that you can choose what sort of inset to goto:
lfun_inset_goto_next "citation"
There are a whole heap of LFUN.*GOTO lfuns that could be collapsed into one...
Maybe that's for another day ;-)
Angus
void LyXText::toggleInset()
{
InsetOld * inset = getInset();
// is there an editable inset at cursor position?
if (!isEditableInset(inset)) {
// No, try to see if we are inside a collapsable inset
if (inset_owner && inset_owner->owner()
&& inset_owner->owner()->isOpen()) {
bv()->unlockInset(inset_owner->owner());
inset_owner->owner()->close(bv());
bv()->getLyXText()->cursorRight(bv());
}
return;
}
//bv()->owner()->message(inset->editMessage());
// do we want to keep this?? (JMarc)
if (!isHighlyEditableInset(inset))
recordUndo(bv(), Undo::ATOMIC);
if (inset->isOpen())
inset->close(bv());
else
inset->open(bv());
bv()->updateInset(inset);
}
Re: Inset::display() ?
On Tue, Sep 02, 2003 at 06:57:13PM +, Angus Leeming spake thusly: > On Tuesday 02 September 2003 5:56 pm, Martin Vermeer wrote: > > > The toggle code in all it's glory is (text3.C): > > >case LFUN_INSET_TOGGLE: > > > bv->beforeChange(this); > > > toggleInset(); > > > bv->update(); > > > bv->switchKeyMap(); > > > break; > > > > > > Angus > > > > ...but am I right in seeing that this code doesn't actually move the > > cursor? I.e., contrary to your description above? > > No, it moves the cursor. See below. All I see is a cursor moving right from under a collapsing inset. That doesn't count :-) > Perhaps you might split this into two and create LFUN_INSET_GOTO_NEXT or some > such? If you get adventurous, you might allow it to take an optional argument > so that you can choose what sort of inset to goto: > lfun_inset_goto_next "citation" > There are a whole heap of LFUN.*GOTO lfuns that could be collapsed into one... > > Maybe that's for another day ;-) Yes ;-) > Angus > > void LyXText::toggleInset() - Martin pgp0.pgp Description: PGP signature
Re: Visible cursor placement
John Levon wrote: > > Try pressing End in a multi-row par in current CVS. Cursor ends up on > the next row, because setCursor() and friends know nothing about which > row the cursor is supposed to be on. Same problem with mouse clicks > (evident before a full row inset like InsetBibtex). > > I can't see a clean fix. Anybody ? What about passing a bool to setCursor? (and/or to store this bool in the cursor) Regards, Alfredo
Re: Visible cursor placement
On Tue, Sep 02, 2003 at 08:29:40PM +0200, Alfredo Braunstein wrote: > What about passing a bool to setCursor? (and/or to store this bool in the what sort of bool and where from, under which circumstances ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Inset::display() ?
On Tuesday 02 September 2003 6:43 pm, Martin Vermeer wrote: > On Tue, Sep 02, 2003 at 06:57:13PM +, Angus Leeming spake thusly: > > On Tuesday 02 September 2003 5:56 pm, Martin Vermeer wrote: > > > > The toggle code in all it's glory is (text3.C): > > > >case LFUN_INSET_TOGGLE: > > > > bv->beforeChange(this); > > > > toggleInset(); > > > > bv->update(); > > > > bv->switchKeyMap(); > > > > break; > > > > > > > > Angus > > > > > > ...but am I right in seeing that this code doesn't actually move the > > > cursor? I.e., contrary to your description above? > > > > No, it moves the cursor. See below. > > All I see is a cursor moving right from under a collapsing inset. That > doesn't count :-) Sigh. Jean Marc's code. Ask him how it is supposed to work. (He is now around again.) As I said, I never tried to code up LFUN_DIALOG_SHOW_NEXT_INSET. Angus
Re: Visible cursor placement
John Levon wrote: > On Tue, Sep 02, 2003 at 08:29:40PM +0200, Alfredo Braunstein wrote: > >> What about passing a bool to setCursor? (and/or to store this bool in the > > what sort of bool and where from, under which circumstances ? bool = "if there is a choice, put me on the next row" put to true when calling setCursor from cursorEnd or whatever needs the cursor at the beginning of the next row. How did it worked before? setCursor transforms it into the right coordinates. Alfredo
getColumnNearX
seems to be causing all this "don't like x please report". Question: why on earth are there floating point variables involved there? Alfredo
Re: Inset::display() ?
On Tue, Sep 02, 2003 at 07:32:00PM +, Angus Leeming spake thusly: > On Tuesday 02 September 2003 6:43 pm, Martin Vermeer wrote: > > On Tue, Sep 02, 2003 at 06:57:13PM +, Angus Leeming spake thusly: > > > On Tuesday 02 September 2003 5:56 pm, Martin Vermeer wrote: ... toggleInset() ... > > > > ...but am I right in seeing that this code doesn't actually move the > > > > cursor? I.e., contrary to your description above? > > > > > > No, it moves the cursor. See below. > > > > All I see is a cursor moving right from under a collapsing inset. That > > doesn't count :-) > > Sigh. Jean Marc's code. Ask him how it is supposed to work. (He is now around > again.) As I said, I never tried to code up LFUN_DIALOG_SHOW_NEXT_INSET. > > Angus Jean-Marc!?! - Martin pgp0.pgp Description: PGP signature
Re: Visible cursor placement
On Tue, Sep 02, 2003 at 08:36:30PM +0200, Alfredo Braunstein wrote: > > what sort of bool and where from, under which circumstances ? > > bool = "if there is a choice, put me on the next row" Hmm, we could pass in a row iterator to say which row the cursor must be placed. That would work I think, but there a lot of places to fix up ... > put to true when calling setCursor from cursorEnd or whatever needs the > cursor at the beginning of the next row. How did it worked before? I have no idea how it worked before. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Inset::display() ?
> You should read better:
> >> > Actually, it's grammatically incorect (read poor use of the
> >> > subjunctive) and should be
> >> > if position x,y were contained in box
> >> > So nuh!
>
> This is all about using the subjunctive in a conditional C++ sentence!
Okay, call me lame and ignorant, but what's wrong with
if box contains position x,y
I hope somebody can explain that so that somebody who knows not much more
besides his spelling can understand :) During my formal English training I
was definitely straying from latin-rooted linguistic terms :)
> > {
> > ...
> > bool contained(whatever) const;
> > inline bool contains(whatever) const { return contained(whatever); }
> > ...
> > }
>
> If this is a joke (and I hope it is), I think I did it before you. ;-)
Sometimes I put such contraptions in the code if I find myself switching
between the two depending on time of the day (or weather :). Makes life
easier -- less compiler error messages, more power to you :) Since with gcc
3.2.1 at least it doesn't increase the code size by a bit (on the optimized
build), there's really no penalty.
Cheers, Kuba Ober
Re: Inset::display() ?
Kuba Ober wrote: >> You should read better: >> >> > Actually, it's grammatically incorect (read poor use of the >> >> > subjunctive) and should be >> >> > if position x,y were contained in box >> >> > So nuh! >> >> This is all about using the subjunctive in a conditional C++ sentence! > > Okay, call me lame and ignorant, but what's wrong with > > if box contains position x,y > > I hope somebody can explain that so that somebody who knows not much more > besides his spelling can understand :) During my formal English training I > was definitely straying from latin-rooted linguistic terms :) There's nothing wrong with it. That's what it should be. In fact... I've just made the change ;-) Summary: These statements are indicative. They describe an actuality: if box contains position x,y. if position x,y is contained by box. This one, however, describes a possible, hypothetical case and so we use the subjunctive: if position x,y were contained by box then the code would be incorrect. It is more commonly written and spoken so (probably incorrectly but, hey, English is an evolving language!) if position x,y was contained by box then the code would be incorrect. hence John's comment about 'was' indicating the past tense. In this case he was wrong. Well, he was probably wrong. ;-) All clear now? -- Angus
cvsignore for frontends/gtk?
I think we need a .cvsignore file for the GTK frontend: ? src/frontends/gtk/Makefile.in ? src/frontends/gtk/glade/Makefile.in ---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: cvsignore for frontends/gtk?
Kayvan A. Sylvan wrote: > I think we need a .cvsignore file for the GTK frontend: > > ? src/frontends/gtk/Makefile.in > ? src/frontends/gtk/glade/Makefile.in Committed. See if that helps... -- Angus
All ps figures the same
I know this was reported some time ago. The lyx view is fine, but the ps view uses the first figure for all the figures. Bug 1313 says it is fixed. Looks like it's back. Is anybody working on this bug? Thanks, Garst
