Vincent van Ravesteijn - TNW wrote:
> >Remember, this is a maintenance release. New features
> >are secondary, our main aim is to make 1.6.x more robust.
>
> I know, but we also have to motivate people to upgrade. Also the people
> that do not experience large problems yet. The higher the version,
> >I think we have enough new features in and we should
> >concentrate on stabilization and crucial issues now
>
> I'm not overwhelmed by the amount of new features.
>
>Remember, this is a maintenance release. New features
>are secondary, our main aim is to make 1.6.x more robust.
I know, but
Vincent van Ravesteijn - TNW wrote:
> >I think we have enough new features in and we should
> >concentrate on stabilization and crucial issues now
>
> I'm not overwhelmed by the amount of new features.
Remember, this is a maintenance release. New features are secondary, our main
aim is to make 1.
>I think we have enough new features in and we should
>concentrate on stabilization and crucial issues now
I'm not overwhelmed by the amount of new features.
>(I know Vincent still has pending patches in the pipe;
>those will be still considered).
Yes, I'm still busy backporting the fixes tha
Looking at status.16x, I see a long, steadily growing list, so I think it's
time for some planning.
I think we have enough new features in and we should concentrate on
stabilization and crucial issues now (I know Vincent still has pending patches
in the pipe; those will be still considered).
H
Le 15 juil. 09 à 20:51, Vincent van Ravesteijn - TNW a écrit :
didn't you remove the parameter from
paragraph_funcs.cpp::acceptChanges ?
if (!isFullyDeleted(copy_pars))
acceptChanges(copy_pars, buf.params());
No. To know its buffer, a paragraph needs to have a valid inset own
On 07/15/2009 06:09 PM, Vincent van Ravesteijn - TNW wrote:
Current trunk: LyX asserts when clicking in a math inset.
There's no problem entering a math inset using the arrow keys.
Still there. Steps to reproduce:
What if you remove "setBuffer(..) {}" from InsetMathSpecialChar ?
On 07/15/2009 05:57 PM, Enrico Forestieri wrote:
On Wed, Jul 15, 2009 at 01:41:28PM +0200, Enrico Forestieri wrote:
Current trunk: LyX asserts when clicking in a math inset.
There's no problem entering a math inset using the arrow keys.
Still there. Steps to reproduce:
1) Ctrl-N
2)
>> Current trunk: LyX asserts when clicking in a math inset.
>> There's no problem entering a math inset using the arrow keys.
>
>Still there. Steps to reproduce:
What if you remove "setBuffer(..) {}" from InsetMathSpecialChar ?
Vincent
On Wed, Jul 15, 2009 at 01:41:28PM +0200, Enrico Forestieri wrote:
> Current trunk: LyX asserts when clicking in a math inset.
> There's no problem entering a math inset using the arrow keys.
Still there. Steps to reproduce:
1) Ctrl-N
2) Ctrl-M
3) Ctrl-M
4) write something
5) Click in the math in
On 07/15/2009 01:22 PM, Jean-Marc Lasgouttes wrote:
Le 15 juil. 09 à 18:47, rgheck a écrit :
I guess I'm wondering why we are performing these sorts of operations
on things in the cut stack. Conceptually, it ought to be nothing but
a place to store things. Are we using the cut stack for purpose
On 07/15/2009 01:19 PM, Jean-Marc Lasgouttes wrote:
Well, the problem here is that InsetMathChar *explicitly* doesn't
have its buffer_ set. Abdel did this at r23362, with the message: "We
don't want a buffer_ member in InsetMathChar." But I don't know why
we wouldn't. In any event, if one remov
>Le 15 juil. 09 à 19:39, Jean-Marc Lasgouttes a écrit :
>> I think setting the buffer to the inset before accepting changes, and
>> resetting it afterwards makes much more sense.
>
>Here is a patch where I re-apply the acceptChanges
>simplification and add some magic code in CutAndPaste.cpp.
>Th
Le 15 juil. 09 à 19:39, Jean-Marc Lasgouttes a écrit :
I think setting the buffer to the inset before accepting changes,
and resetting it
afterwards makes much more sense.
Here is a patch where I re-apply the acceptChanges simplification and
add some magic
code in CutAndPaste.cpp. The casts
Tim Michelsen wrote:
> > if you check that this version works for you, i'll commit it then.
> Can I try it on my Ubuntu installed Lyx by replacing the original file
> (configure.py) with the changed one?
yes that should work(or rather then replace, just patch it).
but the important point is to hav
Le 15 juil. 09 à 19:31, Vincent van Ravesteijn - TNW a écrit :
What we are doing is to accept changes, which makes sense.
It would be possible however to set the buffer temporarily
before accepting the changes, or to accept the changes just
before pasting. Keeping the buffer set on the entries is
Le 15 juil. 09 à 19:23, Vincent van Ravesteijn - TNW a écrit :
Anyway, I propose to commit the attached and see what happens.
It looks very good, especially since adding an empty
setBuffer does not remove the buffer_ member which is
inherited...
Adding ?
Bah. Adding, removing, it is always
>What we are doing is to accept changes, which makes sense.
>It would be possible however to set the buffer temporarily
>before accepting the changes, or to accept the changes just
>before pasting. Keeping the buffer set on the entries is
>asking for trouble, since the buffer they've been copied
>
>>
>> Anyway, I propose to commit the attached and see what happens.
>
>It looks very good, especially since adding an empty
>setBuffer does not remove the buffer_ member which is
>inherited...
Adding ?
>Please apply, and change the assertion from
>+ LASSERT(cur.buffer() == &buffer(), return
Le 15 juil. 09 à 18:47, rgheck a écrit :
I guess I'm wondering why we are performing these sorts of
operations on things in the cut stack. Conceptually, it ought to be
nothing but a place to store things. Are we using the cut stack for
purposes for which it was not perhaps intended? To put i
Well, the problem here is that InsetMathChar *explicitly* doesn't
have its buffer_ set. Abdel did this at r23362, with the message:
"We don't want a buffer_ member in InsetMathChar." But I don't know
why we wouldn't. In any event, if one removes the lines he added
there, then the crash goes
On 07/15/2009 10:40 AM, Jean-Marc Lasgouttes wrote:
lasgout...@lyx.org writes:
revert r30531, which causes a crash when copying an inset.
Basically, insets in cut stack do not have a buffer, and therefore cannot
access to buffer parameters. What is annoying here is that acceptChanges
requir
On 07/15/2009 11:02 AM, Vincent van Ravesteijn - TNW wrote:
Is it possible that the Buffer is being *copied* somewhere in the
mouse code? Since this is checking for the same address, that would
do
it.
When it crashes the Inset::buffer_ is 0. Unfortunately, I hav
"Vincent van Ravesteijn - TNW" writes:
> If Inset::buffer_ is 0, then you'd expect an assert in Inset::buffer()
>
> So, if we get an assert in Inset::dispatch, it comes from cur.buffer()
> ...
No the code is this:
void Inset::dispatch(Cursor & cur, FuncRequest & cmd)
{
//LASSERT(cur.buf
>>>
>> Is it possible that the Buffer is being *copied* somewhere in the
>> mouse code? Since this is checking for the same address, that would
do
>> it.
>
>When it crashes the Inset::buffer_ is 0. Unfortunately, I have
>not been able to find out what inset this is. Try to uncomment
>the ass
Pavel Sanda writes:
[...]
> Tim,
> if you check that this version works for you, i'll commit it then.
Can I try it on my Ubuntu installed Lyx by replacing the original file
(configure.py) with the changed one?
Or do I need to compile Lyx?
Shall I also include other formats?
pandoc also supports
>> Just wandering: wouldn't this be annoying for german-speaking people
>> who don't have a German keyboard ?
>>
>> #: src/frontends/qt4/ui/PrefScreenFontsUi.ui:272
>> msgid "&Larger:"
>> -msgstr "&Größer:"
>> +msgstr "Gr&ößer:"
>>
>> #: src/frontends/qt4/ui/PrefScreenFontsUi.ui:282
>> msg
rgheck writes:
> On 07/15/2009 09:53 AM, lasgout...@lyx.org wrote:
>> Author: lasgouttes
>> Date: Wed Jul 15 15:53:26 2009
>> New Revision: 30602
>> URL: http://www.lyx.org/trac/changeset/30602
>>
>> Log:
>> comment out assertion enabled in r30540. It triggered when entering a math
>> inset with
Jürgen Spitzmüller writes:
> Branch is rather active nowadays (which is a good thing, of course).
> We have so many changes already that I'm beginning to think we should
> soon concentrate on bugfixes only.
You are probably right. I 1.4 times, there were some release where I got
a lot of fixes in
lasgout...@lyx.org writes:
> revert r30531, which causes a crash when copying an inset.
>
> Basically, insets in cut stack do not have a buffer, and therefore cannot
> acess to buffer parameters. What is annoying here is that acceptChanges
> requires this buffer params only to be able to read a fo
>Author: spitz
>Date: Wed Jul 15 16:22:10 2009
>New Revision: 30606
>URL: http://www.lyx.org/trac/changeset/30606
>
>Log:
>* de.po: forwardport translations from branch.
>
>Modified:
> lyx-devel/trunk/po/de.po
>
Just wandering: wouldn't this be annoying for german-speaking people who don't
have
Vincent van Ravesteijn - TNW wrote:
> Just wandering: wouldn't this be annoying for german-speaking people who
> don't have a German keyboard ?
>
> #: src/frontends/qt4/ui/PrefScreenFontsUi.ui:272
> msgid "&Larger:"
> -msgstr "&Größer:"
> +msgstr "Gr&ößer:"
>
> #: src/frontends/qt4/ui/PrefScre
Disregard the previous mail.. Another MS Outlook &#&*$*($&$
Just wandering: wouldn't this be annoying for german-speaking people who don't
have a German keyboard ?
#: src/frontends/qt4/ui/PrefScreenFontsUi.ui:272
msgid "&Larger:"
-msgstr "&Größer:"
+msgstr "Gr&ößer:"
#: src/frontends/qt
Vincent van Ravesteijn - TNW wrote:
> Just wandering: wouldn't this be annoying for german-speaking people who
> don't have a German keyboard ?
What exactly?
Jürgen
On 07/15/2009 09:53 AM, lasgout...@lyx.org wrote:
Author: lasgouttes
Date: Wed Jul 15 15:53:26 2009
New Revision: 30602
URL: http://www.lyx.org/trac/changeset/30602
Log:
comment out assertion enabled in r30540. It triggered when entering a math
inset with the mouse. I have not been able to unde
Uwe Stöhr wrote:
> > New lfuns are allowed.
> >
> > I'm not sure we don't have too much new stuff in 1.6.4, though.
>
> Why do your fear it would harm to have too many backport it?
Because every backport risks to entail new bugs, and your patch is rather big.
> We have 6 new
> features in bran
"Vincent van Ravesteijn - TNW" writes:
> Without these, the diagram becomes quite... trivial.
Yes.
> What about 'fixedinbranch', 'fixedintrunk' ? That is useful for the
> users to know.
Yes, but a bug can be in both states at the same time...
> It would be exciting when these will become real
> New lfuns are allowed.
>
> I'm not sure we don't have too much new stuff in 1.6.4, though.
Why do your fear it would harm to have too many backport it? We have 6 new
features in branch:
http://wiki.lyx.org/LyX/NewInLyX16
but the majority mathematicians and physicists who are working with matri
Uwe Stöhr wrote:
> > It strikes me wrong to do this in the frontend.
>
> > Probably in Buffer::readHeader(Lexer & lex)?
>
> I don't understand. I should enable widgets and set default values for the
> dialog not in GuiDocument?
No, I suspect this resetting is not necessary if the parameters are c
> So, assuming that I used the correct trac.ini, the
> diagram I created and embedded on the following page,
>
> http://wiki.lyx.org/Devel/Administration#Trac_lifecycle
>
> should be our current workflow. Could you (Jean-Marc)
> verify that it's correct?
>
>It looks correct, although I do not think
Christian Ridderström writes:
> So, assuming that I used the correct trac.ini, the diagram I created
> and embedded on the following page,
>
> http://wiki.lyx.org/Devel/Administration#Trac_lifecycle
>
> should be our current workflow. Could you (Jean-Marc) verify that it's
> correct?
It looks cor
> The by far best method, I think, would be to setup a HSpace class similar to
> the VSpace class.
OK, I'll try this.
>> + } else if (token == "\\paragraph_indentation") {
>> + lex.next();
>> + string indentation = lex.getString();
>> + if (indenta
On Sun, 12 Jul 2009, Jean-Marc Lasgouttes wrote:
> Note that bugs are first NEW, and become assigned when someone
> accepts them. We could add a new unconfirmed state.
Do we have some diagram or similar that illustrates the life cycle of
issues? Perhaps useful to show to people reporting bug
Philippe Grosjean writes:
> I want to put everything I did until now about integration of Sweave
> in LyX on a public web server, so that you can look, take what you
> find useful, or start discussions from this basis. Unfortunately, it
> takes me longer than expected to clean up my work. Later t
I want to put everything I did until now about integration of Sweave in
LyX on a public web server, so that you can look, take what you find
useful, or start discussions from this basis. Unfortunately, it takes me
longer than expected to clean up my work. Later today, I hope...
Best,
Philippe
Current trunk: LyX asserts when clicking in a math inset.
There's no problem entering a math inset using the arrow keys.
--
Enrico
I suspect the right thing to use is getLayout().isPassthru.
Martin, do you remember why you chose that instead?
No... but as the comment says, it is probably overkill.
I changed these calls to passthru instead, and kept the 'overkill'
comment.
JMarc
On Tue, 14 Jul 2009 15:47:25 +0200
Jean-Marc Lasgouttes wrote:
> Le 14 juil. 09 à 15:32, lasgout...@lyx.org a écrit :
> > + // FIXME this use of forceLTR is dubious
> > + // introduced in http://www.lyx.org/trac/changeset/21285
> > + if (getLayout().isForceLtr()) {
> > + // Force
Jürgen Spitzmüller wrote:
> Tim Michelsen wrote:
> > Presuming I clean up the formats, is the converter part correct?
>
> Yes, it looks correct.
Tim,
if you check that this version works for you, i'll commit it then.
pavel
Uwe Stöhr wrote:
> Uwe Stöhr schrieb:
>
>> OK, I'll implement this and send a new patch.
>
> Here is the patch.
i hoped that fixing this bug i would be able to set the whole document
paragraph indent to 0. but this didn't happened, when i set 0 it remains
as it was, adding negative number is of no
50 matches
Mail list logo
