Bo Peng wrote:
Ouch... this is a big, non obvious, patch Bo... I am not sure we will
find the time to properly review it and add the missing bits before
1.5.0 :-(
InsetListings ~= InsetERT so you do not have to pay much attention to
it, other than the InsetListingsParams part.
Than why don't
...
> Index: src/insets/Inset.cpp
> ===
> --- src/insets/Inset.cpp (revision 18187)
> +++ src/insets/Inset.cpp (working copy)
> @@ -76,6 +76,7 @@
> InsetName("bibtex", Inset::BIBTEX_CODE),
> Inse
On Thu, May 03, 2007 at 03:07:58PM -0500, Bo Peng wrote:
> >
> > What do you need?
>
> I am attaching what I have right now. Many parts are missing but the
> main points are there:
>
> What I have got:
...
> Index: src/insets/Inset.cpp
> ===
Ouch... this is a big, non obvious, patch Bo... I am not sure we will
find the time to properly review it and add the missing bits before
1.5.0 :-(
InsetListings ~= InsetERT so you do not have to pay much attention to
it, other than the InsetListingsParams part.
Many other small changes are sta
On Thu, 3 May 2007, Michael Gerz wrote:
José Matos schrieb:
On Thursday 03 May 2007 19:40:06
[EMAIL PROTECTED] wrote:
> Good points. Does this mean you've approved the schedule above?
>
The calendar is optimistic, and I am not know for being pessimistic. ;-)
You should, if possibl
On Thu, 3 May 2007, Bo Peng wrote:
we have to be very careful with InsetListings! If we add a half-baked
solution, people will be nagging all the time, i.e., we will be flooded
by countless bug reports ("Listing does not support this, Listing does
not support that").
I am using a list of s
Bo Peng wrote:
What do you need?
I am attaching what I have right now. Many parts are missing but the
main points are there:
Ouch... this is a big, non obvious, patch Bo... I am not sure we will
find the time to properly review it and add the missing bits before
1.5.0 :-(
What I have
I am attaching what I have right now. Many parts are missing but the
main points are there:
Sorry, last patch does not have InsetListingsParams.h/cpp.
Bo
Index: src/LyXAction.cpp
===
--- src/LyXAction.cpp (revision 18187)
+++ src/L
What do you need?
I am attaching what I have right now. Many parts are missing but the
main points are there:
What I have got:
1. add InsetListings in file InsetListings.h and InsetListings.cpp,
this is a slightly modified copy of InsetERT. It already works in the
sense that you can insert
On Thursday 03 May 2007 20:38:00 Michael Gerz wrote:
> Point taken. But all hobby-horses have to be stopped by beta 3, even if
> it hurts (no matter how important or smart they are). IMHO things like
> icons rescaling falls into this category, too.
I agree and I count with every developer to imp
On Thursday 03 May 2007 15:49:06 Bo Peng wrote:
> > You know of course that you have the power to implement everything you
> > want locally don't you? :-)
>
> But another guy in my group will collaborate with me on this document
> and it would be easier for him if it is in lyx.1.5.0.
Since this
we have to be very careful with InsetListings! If we add a half-baked
solution, people will be nagging all the time, i.e., we will be flooded
by countless bug reports ("Listing does not support this, Listing does
not support that").
I am using a list of string method to handle all listings optio
Bo Peng schrieb:
Beta 3: Friday, May 11
RC1: Friday, May 25
Final : Friday, June 1 (unless a new critical bug appear)
No file format changes and new features after beta 3 - only bug fixing!
I see that I am given one week to add InsetListings ...
Bo,
we have to be very careful with Inse
José Matos schrieb:
On Thursday 03 May 2007 17:51:25 Michael Gerz wrote:
Beta 3: Friday, May 11
RC1: Friday, May 25
Final : Friday, June 1 (unless a new critical bug appear)
No file format changes and new features after beta 3 - only bug fixing!
Those two conditions are not ne
José Matos schrieb:
On Thursday 03 May 2007 19:40:06 [EMAIL PROTECTED] wrote:
Good points. Does this mean you've approved the schedule above?
The calendar is optimistic, and I am not know for being pessimistic. ;-)
You should, if possible, try to have some weekly list of the most
On Thursday 03 May 2007 19:40:06 [EMAIL PROTECTED] wrote:
> Good points. Does this mean you've approved the schedule above?
The calendar is optimistic, and I am not know for being pessimistic. ;-)
You should, if possible, try to have some weekly list of the most critical
bugs. Think in somet
On Thu, 3 May 2007, José Matos wrote:
On Thursday 03 May 2007 17:51:25 Michael Gerz wrote:
Beta 3: Friday, May 11
RC1: Friday, May 25
Final : Friday, June 1 (unless a new critical bug appear)
No file format changes and new features after beta 3 - only bug fixing!
Those two conditions
On Thu, 3 May 2007, Bo Peng wrote:
Beta 3: Friday, May 11
RC1: Friday, May 25
Final : Friday, June 1 (unless a new critical bug appear)
No file format changes and new features after beta 3 - only bug fixing!
I see that I am given one week to add InsetListings ...
Isn't that enough
On Thursday 03 May 2007 17:51:25 Michael Gerz wrote:
>
> Beta 3: Friday, May 11
> RC1: Friday, May 25
> Final : Friday, June 1 (unless a new critical bug appear)
>
> No file format changes and new features after beta 3 - only bug fixing!
Those two conditions are not necessarily both satisf
Beta 3: Friday, May 11
RC1: Friday, May 25
Final : Friday, June 1 (unless a new critical bug appear)
No file format changes and new features after beta 3 - only bug fixing!
I see that I am given one week to add InsetListings ...
Bo
Abdelrazak Younes schrieb:
José Matos wrote:
On Thursday 03 May 2007 12:54:28 [EMAIL PROTECTED] wrote:
I don't think that's a good idea as we expect the file format to change
between the rc and the stable release.
I am sorry, I can't parse this sentence. :-)
IMO, it is all a matter of ti
On Thu, 3 May 2007, José Matos wrote:
I am sorry, I can't parse this sentence. :-)
Here's what I actually meant:
I don't think that's a good idea, as we _would_then_ expect the
file format to change between the rc and the stable release.
So I think a RC would be bad when we
You know of course that you have the power to implement everything you
want locally don't you? :-)
But another guy in my group will collaborate with me on this document
and it would be easier for him if it is in lyx.1.5.0.
Will this feature involves a format change? If yes, how much time do yo
> I sincerely hope that 1.5.0 will be out in less than a month. IMHO we
> should set a fixed data for 1.5.0. First of June seems good to me. Bug
> that won't be fixed within a month won't be fixed either in one year.
+1
José Matos wrote:
On Thursday 03 May 2007 12:54:28 [EMAIL PROTECTED] wrote:
I don't think that's a good idea as we expect the file format to change
between the rc and the stable release.
I am sorry, I can't parse this sentence. :-)
IMO, it is all a matter of timings, if we release in a we
On Thursday 03 May 2007 12:54:28 [EMAIL PROTECTED] wrote:
> I don't think that's a good idea as we expect the file format to change
> between the rc and the stable release.
I am sorry, I can't parse this sentence. :-)
IMO, it is all a matter of timings, if we release in a week it makes sense
On Thu, 3 May 2007, Abdelrazak Younes wrote:
Leuven, E. wrote:
> Yes, IMO another beta to shaken out any possible bugs due to the file
> name changes and then we start with the release candidate cycle.
> What do others think?
i would put out rc1
I did not dare proposing it ;-)
I don'
Leuven, E. wrote:
Yes, IMO another beta to shaken out any possible bugs due to the file
name changes and then we start with the release candidate cycle.
What do others think?
i would put out rc1
I did not dare proposing it ;-)
Abdel.
> Yes, IMO another beta to shaken out any possible bugs due to the file
> name changes and then we start with the release candidate cycle.
> What do others think?
i would put out rc1
José Matos wrote:
On Wednesday 02 May 2007 22:17:54 [EMAIL PROTECTED] wrote:
I also wondered about this?
What's the plan for getting to 1.5.0? Another beta?
Yes, IMO another beta to shaken out any possible bugs due to the file name
changes and then we start with the release candidate cycl
On Thursday 03 May 2007 07:59:18 Abdelrazak Younes wrote:
> Will this feature involves a format change? If yes, how much time do you
> need in order to implement the very minimal change to support it? If no,
> then I suggest that you develop this feature and use it locally. We will
> then integrate
On Thu, 3 May 2007, José Matos wrote:
On Wednesday 02 May 2007 22:17:54 [EMAIL PROTECTED] wrote:
I also wondered about this?
What's the plan for getting to 1.5.0? Another beta?
Yes, IMO another beta to shaken out any possible bugs due to the file
name changes and then we start with the re
On Wednesday 02 May 2007 22:17:54 [EMAIL PROTECTED] wrote:
> I also wondered about this?
>
> What's the plan for getting to 1.5.0? Another beta?
Yes, IMO another beta to shaken out any possible bugs due to the file name
changes and then we start with the release candidate cycle.
What do oth
Bo Peng wrote:
> Another one is too little focus on 1.5.0 release. For example,
restarting
> the work on insetlisting now is ridicolous.
I have never been a model developer in this regard because I had never
'focused' on 1.5.0 due to my very limited time.
OK, I'll try to give you some focus
> Another one is too little focus on 1.5.0 release. For example, restarting
> the work on insetlisting now is ridicolous.
I have never been a model developer in this regard because I had never
'focused' on 1.5.0 due to my very limited time. This time, I *really*
need this feature for my own work
35 matches
Mail list logo
