Andre Poenitz wrote:
What does
cvs update: move away support/tests/ChangeLog; it is in the way
C support/tests/ChangeLog
cvs update: move away support/tests/Makefile.am; it is in the way
C support/tests/Makefile.am
cvs update: move away support/tests/boost.C; it is in the way
C support/tests/boost.
What does
cvs update: move away support/tests/ChangeLog; it is in the way
C support/tests/ChangeLog
cvs update: move away support/tests/Makefile.am; it is in the way
C support/tests/Makefile.am
cvs update: move away support/tests/boost.C; it is in the way
C support/tests/boost.C
cvs update: move
On Fri, May 06, 2005 at 08:28:47PM +0200, Andre Poenitz wrote:
> On Fri, May 06, 2005 at 03:59:47PM +0300, Martin Vermeer wrote:
> > But there is no graphics or the like within a mile.
> > It is _typing characters_ that does this. Does that ring a bell?
>
> Could I please have once more a recipe t
On Fri, May 06, 2005 at 08:19:06PM +0200, Andre Poenitz wrote:
> On Fri, May 06, 2005 at 04:01:26PM +0100, Angus Leeming wrote:
> > As soon as you have acknowledged the recursive nature of the current
> > update(), then something like this was bound to be needed. Well done for
> > getting to grip
On Fri, May 06, 2005 at 08:10:23PM +0200, Andre Poenitz wrote:
> On Fri, May 06, 2005 at 05:48:34PM +0300, Martin Vermeer wrote:
> > On Fri, 2005-05-06 at 15:28, Martin Vermeer wrote:
> >
> > >
> > > The second reported crash still happens, but is rarer and presumably
> > > unrelated:
> > >
> >
On Fri, May 06, 2005 at 08:28:13PM +0300, Martin Vermeer wrote:
> On Fri, May 06, 2005 at 06:46:16PM +0200, Andre Poenitz wrote:
> >
> > This fixes a hard crash when switching ERT using the dialog to 'collapsed'
> > while the cursor is inside the inset (the actual fix is the insertert.C
> > relate
On Fri, May 06, 2005 at 10:55:16AM +0100, Angus Leeming wrote:
> Juergen Spitzmueller wrote:
>
> > In LyXFunc::dispatch, case LFUN_INSET_APPLY, there's an update call
> > missing. You see it when you apply changes from an inset dialog. You have
> > to do some keyboard action until the changes get
On Fri, May 06, 2005 at 11:55:29AM +0200, Juergen Spitzmueller wrote:
> In LyXFunc::dispatch, case LFUN_INSET_APPLY, there's an update call missing.
> You see it when you apply changes from an inset dialog. You have to do some
> keyboard action until the changes get visible.
>
> The attached pat
On Fri, May 06, 2005 at 04:01:26PM +0100, Angus Leeming wrote:
> As soon as you have acknowledged the recursive nature of the current
> update(), then something like this was bound to be needed. Well done for
> getting to grips with it all.
I understand (now) that update() might be called recurs
On Fri, May 06, 2005 at 11:57:47AM +0300, Martin Vermeer wrote:
> > Both seem to point so some asynchronous inconsistency.
> >
> > 1) how come another call to insettext draw happens after screen redraw
> > is already over?
> >
> > 2) Why two calls to doneUpdating, of which the second of course f
On Fri, May 06, 2005 at 03:59:47PM +0300, Martin Vermeer wrote:
> But there is no graphics or the like within a mile.
> It is _typing characters_ that does this. Does that ring a bell?
Could I please have once more a recipe to produce that kind of crash?
Andre'
On Fri, May 06, 2005 at 05:48:34PM +0300, Martin Vermeer wrote:
> On Fri, 2005-05-06 at 15:28, Martin Vermeer wrote:
>
> >
> > The second reported crash still happens, but is rarer and presumably
> > unrelated:
> >
> > # InsetTabular::getNearestCell() x=82 y=150
> > Assertion triggered in pit_t
On Fri, May 06, 2005 at 07:21:27PM +0200, Georg Baum wrote:
> Index: ui/BiblioModuleBase.ui
Seems OK to me.
john
On Fri, May 06, 2005 at 06:46:16PM +0200, Andre Poenitz wrote:
>
> This fixes a hard crash when switching ERT using the dialog to 'collapsed'
> while the cursor is inside the inset (the actual fix is the insertert.C
> related chunk)
>
> The last chunk fixes a second by adding an unconditional 'up
John Levon wrote:
> Sorry, can I see the text changes again??
>
> john
Index: ui/BiblioModuleBase.ui
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/ui/BiblioModuleBase.ui,v
retrieving revision 1.5
diff -u -p -r1.5 BiblioModuleB
On Fri, May 06, 2005 at 07:08:06PM +0200, Georg Baum wrote:
> I think the patch is nice, but as non-native english speaker I can not
> really judge the text changes. Was there consensus that they are good
Sorry, can I see the text changes again??
john
This fixes a hard crash when switching ERT using the dialog to 'collapsed'
while the cursor is inside the inset (the actual fix is the insertert.C
related chunk)
The last chunk fixes a second by adding an unconditional 'update'
when e.g. 'apply' is clicked in the ERT dialog.
Andre'
--- ./src/fr
Michael Schmitt wrote:
> IMHO it is really questionable whether it is a good idea to let the LyX
> backend fix the dialog titles of the frontend. But, given the current
> design, I think this patch is correct and simple.
Given the fact that LyX supports several frontends it is good to set the
tit
Michael Schmitt wrote:
Dear Qt Win/Free developers,
this is the last bug report for today. In LyX, there is a dialog that
looks as follows:
Sorry, the thunderbird ate my screen shot. Please have a look at the
attachment.
Michael
<>
Dear Qt Win/Free developers,
this is the last bug report for today. In LyX, there is a dialog that
looks as follows:
On the right, there is a scrollable list of buttons which are decorated
with graphical symbols (you can click on any of these symbols).
Unfortunately, the scroll bar does not w
Hello again!
There is a problem in the Qt3/Win Free file dialog: If you want to
select some text in the "Filename" field, some characters disappear
temporarily.
The problem is simply reproducible: Click into the "Filename" field and
press "Shift + CursorLeft" or "Shift + CursorRight" (maybe mul
In src/support/fs_extras.C, shouldn't it be thus:
void copy_file(path const & source, path const & target, bool noclobber)
{
#ifdef BOOST_POSIX
...
#endif
#ifdef BOOST_WINDOWS
- if (::CopyFile(source.string().c_str(), target.string().c_str(),
!noclobber) == 0) {
+ if (::CopyFile(sourc
Martin Vermeer wrote:
> This is fixed by the attached, which simply shunts out cursor up/down
> for the duration of screen redraw / coordinate cache maintenance.
>
> The problem was again, that the cursor got ahead of itself and went to a
> cell below or above with the coordinate cache in statu na
Martin Vermeer wrote:
> On Fri, 2005-05-06 at 15:28, Martin Vermeer wrote:
>
>>
>> The second reported crash still happens, but is rarer and presumably
>> unrelated:
>>
>> # InsetTabular::getNearestCell() x=82 y=150
>> Assertion triggered in pit_type LyXText::getPitNearY(int) const by
>> faili
On Fri, 2005-05-06 at 15:28, Martin Vermeer wrote:
>
> The second reported crash still happens, but is rarer and presumably
> unrelated:
>
> # InsetTabular::getNearestCell() x=82 y=150
> Assertion triggered in pit_type LyXText::getPitNearY(int) const by
> failing check "theCoords.getParPos().fi
On Friday 06 May 2005 15:32, Angus Leeming wrote:
> Here's the wrapper script to configure that I use. Edit the options to
> suit.
I will do. :-)
Thank you.
--
Josà AbÃlio
On Wednesday 04 May 2005 12:20, Jose' Matos wrote:
>
> Bah, I don't like loops especially if I can avoid them. So the easier
> solution was simply to remove the need for such loop.
Committed.
> > I know just enough Python to understand that someone else should
> > provide the patch for this :-
Jose' Matos wrote:
> On Thursday 05 May 2005 19:27, Angus Leeming wrote:
>>
>> "char const b" (and c) wouldn't hurt though :)
>
> Done. Committed.
>
>> Also, if your used a separate build tree from your source tree, you
>> wouldn't have those
>>
>> ? frontends/gtk/pch.h.gch
>> ? frontends/gtk/
On Thursday 05 May 2005 19:27, Angus Leeming wrote:
>
> "char const b" (and c) wouldn't hurt though :)
Done. Committed.
> Also, if your used a separate build tree from your source tree, you
> wouldn't have those
>
> ? frontends/gtk/pch.h.gch
> ? frontends/gtk/pch.h.gch.dep
>
> :-P
True but e
Martin Vermeer wrote:
> But there is no graphics or the like within a mile.
> It is _typing characters_ that does this. Does that ring a bell?
No, but bv.update() is called from an obscene number of places:
src/BufferView.C:279: update();
src/BufferView_pimpl.C:367: update();
src/Bu
Hello,
I have created a patch that removes all dialog titles from the Qt ui
files + makes a few additional text changes.
As mentioned in one of my previous emails, the effective dialog titles
are set in the corresponding *.C files. I.e. the captions in the ui
files are ignored and pollute the p
On Fri, 2005-05-06 at 15:48, Angus Leeming wrote:
...
> > This fixes the first crash reported by Juergen.
> >
> > It turns out BufferView::update() can in fact be called multiple times
> > at the same time, if you press keys fast enough. I wonder if this is
> > supposed to be. Anyway, making the
Martin Vermeer wrote:
>
>> Yes, I am getting the attached full output.
>>
>> Note (line 175) that the screen redraw is pre-empted by processing the
>> character 'a'... so it doesn't get around to calling doneUpdating.
>>
>> Then, at line 604, it finally comes tumbling from the sky ;-)
>>
>> I
Wrong attachment. Try again.
- Martin
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.581
diff -u -p -r1.581 BufferView_pimpl.C
--- BufferView_pimpl.C 20 Apr 2005
> Yes, I am getting the attached full output.
>
> Note (line 175) that the screen redraw is pre-empted by processing the
> character 'a'... so it doesn't get around to calling doneUpdating.
>
> Then, at line 604, it finally comes tumbling from the sky ;-)
>
> I expect this would work fine if we
Georg Baum wrote:
> I think that Jürgens patch is fine, I would however add a comment stating
> that in an ideal world 'update' would be set by the inset.
I did so and committed.
Jürgen
Angus Leeming wrote:
> I'm not saying it's wrong, but I note that 'update' is specified in very
> few places in this function. Do all insets change there visible appearance
> on LFUN_INSET_APPLY or should this 'update' flag be set by indvidual
> insets.
>
> Just thinking out aloud.
In theory not
Juergen Spitzmueller wrote:
> In LyXFunc::dispatch, case LFUN_INSET_APPLY, there's an update call
> missing. You see it when you apply changes from an inset dialog. You have
> to do some keyboard action until the changes get visible.
>
> The attached patch adds the update call.
>
> OK?
>
> Jürg
In LyXFunc::dispatch, case LFUN_INSET_APPLY, there's an update call missing.
You see it when you apply changes from an inset dialog. You have to do some
keyboard action until the changes get visible.
The attached patch adds the update call.
OK?
Jürgen
Index: lyxfunc.C
=
Martin Vermeer wrote:
>> As for "how?", well you pass m.base.textwidth to LyXText::metrics() from
>> InsetText::metrics(), but I'm damn sure you don't use it. (German "man",
>> French "on", English "you". We're much more direct :) And "one" just
>> sounds pretentious.)
>
> Oh yes, you (and me :) d
On Fri, 2005-05-06 at 12:05, Angus Leeming wrote:
> Martin Vermeer wrote:
> >> > Keeping the dim_ cache valid between phase 1 and 2 is (in theory...)
> >> > crucial for the whole drawing scheme...
> >>
> >> Yes, so
> >> dim_ = dim;
> >> dim.wid = m.base.textwidth;
> >> which is what this p
Martin Vermeer wrote:
>> > Keeping the dim_ cache valid between phase 1 and 2 is (in theory...)
>> > crucial for the whole drawing scheme...
>>
>> Yes, so
>> dim_ = dim;
>> dim.wid = m.base.textwidth;
>> which is what this patch proposes is just looking for trouble.
>
> How then to achiev
On Fri, 2005-05-06 at 11:37, Martin Vermeer wrote:
> Both seem to point so some asynchronous inconsistency.
>
> 1) how come another call to insettext draw happens after screen redraw
> is already over?
>
> 2) Why two calls to doneUpdating, of which the second of course fails?
Yes, I am gettin
Ãsh, incomplete patch. Attached is better.
- Martin
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.581
diff -u -p -r1.581 BufferView_pimpl.C
--- BufferView_pimpl
On Fri, 2005-05-06 at 09:28, Martin Vermeer wrote:
> On Thu, 2005-05-05 at 17:25, Juergen Spitzmueller wrote:
>
> >
> > 2. LyX asserts when you move the cursor to another cell with the mouse and
> > then type something _while_ the tabular dialog is opened.
> > I get two different asserts:
> >
>
On Fri, 2005-05-06 at 10:46, Angus Leeming wrote:
> >>
> >> tabular.getCellInset(cell)->metrics(m, dim);
> >> + if (!p_width.zero())
> >> + dim.wid = m.base.textwidth;
> >>
> >> Well, I can see what it does, but it seems a bit ugly. Surely, this
> >> should be happening inside
Andre Poenitz wrote:
> On Thu, May 05, 2005 at 03:09:36PM +0100, Angus Leeming wrote:
>> Martin Vermeer wrote:
>>
>> > Attached, please review
>> >
>> > - Martin
>>
>> tabular.getCellInset(cell)->metrics(m, dim);
>> + if (!p_width.zero())
>> + dim.wid = m.base.textwidth;
>>
>
On Fri, 2005-05-06 at 10:26, Andre Poenitz wrote:
> On Thu, May 05, 2005 at 03:09:36PM +0100, Angus Leeming wrote:
> > Martin Vermeer wrote:
> >
> > > Attached, please review
> > >
> > > - Martin
> >
> > tabular.getCellInset(cell)->metrics(m, dim);
> > + if (!p_width.zero())
> > +
On Thu, May 05, 2005 at 05:23:56PM +0100, Angus Leeming wrote:
> Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
Only for cmd.lenght() == -1.
Andre'
On Thu, May 05, 2005 at 03:09:36PM +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
>
> > Attached, please review
> >
> > - Martin
>
> tabular.getCellInset(cell)->metrics(m, dim);
> + if (!p_width.zero())
> + dim.wid = m.base.textwidth;
>
> Well, I can see what it does, but
50 matches
Mail list logo
