Re: LyX components?
"Allan" == Allan Rae [EMAIL PROTECTED] writes:
Allan On Thu, 10 Feb 2000, Asger K. Alstrup Nielsen wrote:
Right now, we need stability more than the new painter if you ask
me. People say that 1.1.2 was more stable than what we have now.
That's the wrong direction. 1.1.5 should be more stable than 1.1.2!
Allan Which is why I haven't sent my PR statement anywhere. At least
Allan not till I remove the bits about "most stable ever".
I have accumulated small safe patches for 1.1.4 (currently is 1698
bytes) which I plan to make available as a short patch, mainly for
rpm/deb packagers. The fixes it contains now are
- iso-8899-1.cdef \"{e} fixed
- "oneside" option fix when exporting to latex
- \date_insert_format fix
If you have other things that are
- _not_ new features
- short enough that they are obviously right
- fixing a real problem
then tell me, and I'll add them.
The intent is to avoid the pressure on releasing new lyx versions
because of bugs. I'm not sure yet on the naming scheme (1.1.4+,
1.1.4.1, 1.1.4fix1...).
JMarc
Re: LyX components?
"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes: | Ok, I should not have followed up to this mail, but I wanted Asgers | attention... | | Hey! I read almost all of the traffic on the list. And how could I know that? (my lurking-radar is out of order) | [Changes in LyXFont] | Do you have any other/better ideas on how to do this? I think that | after my changes it is a lot clearer what is going on in lowlevel | LyXFont code, so from a maintence viewpoint the changes are good. | | The LyXFont code should be split into two different parts: | one for LyX abstract representation of fonts, and one | for the concrete instance of fonts in the GUI. | | Therefore, it's ok to clean up the font code even at the price of | performance, but only if the work is followed up by the split in | font representation that will make the performance problem less | acute. I don't think performance will suffer a lot... | But only in due time! | | Small steps, remember? The font change is a small step... | Anyway I will check this in, and then you can have a look. | | I'm a little surprised that you did this work at this stage, | although I understand that it's more fun. ok, this step is a bit larger. BUT this change is absolutely needed for the gui-independence work and to allow further work on insets/tabulars etc. to happen. I agree that it is a bit bold, but what we did cleanly at our meeting now pays off, the inclusion of the Painter code was easy (but a lot of work). | However, please consider to spent some time to finish the space issues | in tables double space? | and extremes of paragraphs, and fix some of the other | bugs that have been reported recently. We can of course stop all development and just fix bugs... that will quickly make the next version of LyX the most stable ever (or the next version after that), but then at least I as a developer will get completely bored and not do anything... As you have claimed yourself: Fix one bug and you are entitled to write one new feature. | Right now, we need stability more than the new painter if you ask me. | People say that 1.1.2 was more stable than what we have now. That's | the wrong direction. 1.1.5 should be more stable than 1.1.2! Only true under the assumtion that no development are done. Lgb
Re: LyX components?
The intent is to avoid the pressure on releasing new lyx versions because of bugs. I'm not sure yet on the naming scheme (1.1.4+, 1.1.4.1, 1.1.4fix1...). 1.1.4fix1 would fit best into the ...pre... naming scheme... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: LyX components?
"Andre" == Andre Poenitz [EMAIL PROTECTED] writes: The intent is to avoid the pressure on releasing new lyx versions because of bugs. I'm not sure yet on the naming scheme (1.1.4+, 1.1.4.1, 1.1.4fix1...). Andre 1.1.4fix1 would fit best into the ...pre... naming scheme... Yes, I think I'll do that. I'll wait a bit to see whether I have other things to put in it. What are people favourite problems with 1.1.4? Maybe fixing kpsewhich searching... JMarc
Re: LyX components?
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> On Thu, 10 Feb 2000, Asger K. Alstrup Nielsen wrote:
>> Right now, we need stability more than the new painter if you ask
>> me. People say that 1.1.2 was more stable than what we have now.
>> That's the wrong direction. 1.1.5 should be more stable than 1.1.2!
Allan> Which is why I haven't sent my PR statement anywhere. At least
Allan> not till I remove the bits about "most stable ever".
I have accumulated small safe patches for 1.1.4 (currently is 1698
bytes) which I plan to make available as a short patch, mainly for
rpm/deb packagers. The fixes it contains now are
- iso-8899-1.cdef \"{e} fixed
- "oneside" option fix when exporting to latex
- \date_insert_format fix
If you have other things that are
- _not_ new features
- short enough that they are obviously right
- fixing a real problem
then tell me, and I'll add them.
The intent is to avoid the pressure on releasing new lyx versions
because of bugs. I'm not sure yet on the naming scheme (1.1.4+,
1.1.4.1, 1.1.4fix1...).
JMarc
Re: LyX components?
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes: | > Ok, I should not have followed up to this mail, but I wanted Asgers | > attention... | | Hey! I read almost all of the traffic on the list. And how could I know that? (my lurking-radar is out of order) | [Changes in LyXFont] | > Do you have any other/better ideas on how to do this? I think that | > after my changes it is a lot clearer what is going on in lowlevel | > LyXFont code, so from a maintence viewpoint the changes are good. | | The LyXFont code should be split into two different parts: | one for LyX abstract representation of fonts, and one | for the concrete instance of fonts in the GUI. | | Therefore, it's ok to clean up the font code even at the price of | performance, but only if the work is followed up by the split in | font representation that will make the performance problem less | acute. I don't think performance will suffer a lot... | But only in due time! | | Small steps, remember? The font change is a small step... | > Anyway I will check this in, and then you can have a look. | | I'm a little surprised that you did this work at this stage, | although I understand that it's more fun. ok, this step is a bit larger. BUT this change is absolutely needed for the gui-independence work and to allow further work on insets/tabulars etc. to happen. I agree that it is a bit bold, but what we did cleanly at our meeting now pays off, the inclusion of the Painter code was easy (but a lot of work). | However, please consider to spent some time to finish the space issues | in tables double space? | and extremes of paragraphs, and fix some of the other | bugs that have been reported recently. We can of course stop all development and just fix bugs... that will quickly make the next version of LyX the most stable ever (or the next version after that), but then at least I as a developer will get completely bored and not do anything... As you have claimed yourself: Fix one bug and you are entitled to write one new feature. | Right now, we need stability more than the new painter if you ask me. | People say that 1.1.2 was more stable than what we have now. That's | the wrong direction. 1.1.5 should be more stable than 1.1.2! Only true under the assumtion that no development are done. Lgb
Re: LyX components?
> The intent is to avoid the pressure on releasing new lyx versions > because of bugs. I'm not sure yet on the naming scheme (1.1.4+, > 1.1.4.1, 1.1.4fix1...). 1.1.4fix1 would fit best into the ...pre... naming scheme... Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: LyX components?
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: >> The intent is to avoid the pressure on releasing new lyx versions >> because of bugs. I'm not sure yet on the naming scheme (1.1.4+, >> 1.1.4.1, 1.1.4fix1...). Andre> 1.1.4fix1 would fit best into the ...pre... naming scheme... Yes, I think I'll do that. I'll wait a bit to see whether I have other things to put in it. What are people favourite problems with 1.1.4? Maybe fixing kpsewhich searching... JMarc
Re: LyX components?
What I'm looking for is basically any code which could help in this task: - a parser for LaTex formulas (we'll probably support a subset of the whole LaTex stuff...) - code to render them on screen (possibly in Qt...) - code to produce PostScript. Do you think I may find any of those in the LyX code? Not in a state where they are easily reusable for other projects. Greets, Asger
Re: LyX components?
"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes: | Not in a state where they are easily reusable for other projects. Ok, I should not have followed up to this mail, but I wanted Asgers attention... Asger, I have now ported the painter,workarea and lcolor code form the old devel repository. During this I found out that we had enlarged the color bits in LyXFont from 4 to 6 and this is needed. But in the meantime we have had the addition of the hebrew patch that needs 3 bits in the LyXFont::bits structure and thus we don't have room for the needed color bits anymore. I have rewritten the bits to be a structure of the font variables, and use a static FontBits sane (+ etc) to heep the nice fast constructors. Do you have any other/better ideas on how to do this? I think that after my changes it is a lot clearer what is going on in lowlevel LyXFont code, so from a maintence viewpoint the changes are good. Anyway I will check this in, and then you can have a look. Lgb
Re: LyX components?
Ok, I should not have followed up to this mail, but I wanted Asgers attention... Hey! I read almost all of the traffic on the list. [Changes in LyXFont] Do you have any other/better ideas on how to do this? I think that after my changes it is a lot clearer what is going on in lowlevel LyXFont code, so from a maintence viewpoint the changes are good. The LyXFont code should be split into two different parts: one for LyX abstract representation of fonts, and one for the concrete instance of fonts in the GUI. Therefore, it's ok to clean up the font code even at the price of performance, but only if the work is followed up by the split in font representation that will make the performance problem less acute. But only in due time! Small steps, remember? Anyway I will check this in, and then you can have a look. I'm a little surprised that you did this work at this stage, although I understand that it's more fun. However, please consider to spent some time to finish the space issues in tables and extremes of paragraphs, and fix some of the other bugs that have been reported recently. Right now, we need stability more than the new painter if you ask me. People say that 1.1.2 was more stable than what we have now. That's the wrong direction. 1.1.5 should be more stable than 1.1.2! Greets, Asger
Re: LyX components?
"Dino" == Dino Ferrero [EMAIL PROTECTED] writes: Dino - a parser for LaTex formulas (we'll probably support a subset Dino of the whole LaTex stuff...) Yes, LyX has that in math_parse.C Dino - code to render them on screen (possibly in Qt...) LyX has that too. However, the KDE project has something named KFormula that could be very useful too. Dino - code to produce PostScript. Hmm, Qt does that for you doesn't it? JMarc
Re: LyX components?
On Thu, 10 Feb 2000, Asger K. Alstrup Nielsen wrote: Right now, we need stability more than the new painter if you ask me. People say that 1.1.2 was more stable than what we have now. That's the wrong direction. 1.1.5 should be more stable than 1.1.2! Which is why I haven't sent my PR statement anywhere. At least not till I remove the bits about "most stable ever". Allan. (ARRae)
Re: LyX components?
> What I'm looking for is basically any code which could help in this > task: > > - a parser for LaTex formulas (we'll probably support a subset of the > whole > LaTex stuff...) > > - code to render them on screen (possibly in Qt...) > > - code to produce PostScript. > > Do you think I may find any of those in the LyX code? Not in a state where they are easily reusable for other projects. Greets, Asger
Re: LyX components?
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes: | Not in a state where they are easily reusable for other projects. Ok, I should not have followed up to this mail, but I wanted Asgers attention... Asger, I have now ported the painter,workarea and lcolor code form the old devel repository. During this I found out that we had enlarged the color bits in LyXFont from 4 to 6 and this is needed. But in the meantime we have had the addition of the hebrew patch that needs 3 bits in the LyXFont::bits structure and thus we don't have room for the needed color bits anymore. I have rewritten the bits to be a structure of the font variables, and use a static FontBits sane (+ etc) to heep the nice fast constructors. Do you have any other/better ideas on how to do this? I think that after my changes it is a lot clearer what is going on in lowlevel LyXFont code, so from a maintence viewpoint the changes are good. Anyway I will check this in, and then you can have a look. Lgb
Re: LyX components?
> Ok, I should not have followed up to this mail, but I wanted Asgers > attention... Hey! I read almost all of the traffic on the list. [Changes in LyXFont] > Do you have any other/better ideas on how to do this? I think that > after my changes it is a lot clearer what is going on in lowlevel > LyXFont code, so from a maintence viewpoint the changes are good. The LyXFont code should be split into two different parts: one for LyX abstract representation of fonts, and one for the concrete instance of fonts in the GUI. Therefore, it's ok to clean up the font code even at the price of performance, but only if the work is followed up by the split in font representation that will make the performance problem less acute. But only in due time! Small steps, remember? > Anyway I will check this in, and then you can have a look. I'm a little surprised that you did this work at this stage, although I understand that it's more fun. However, please consider to spent some time to finish the space issues in tables and extremes of paragraphs, and fix some of the other bugs that have been reported recently. Right now, we need stability more than the new painter if you ask me. People say that 1.1.2 was more stable than what we have now. That's the wrong direction. 1.1.5 should be more stable than 1.1.2! Greets, Asger
Re: LyX components?
> "Dino" == Dino Ferrero <[EMAIL PROTECTED]> writes: Dino> - a parser for LaTex formulas (we'll probably support a subset Dino> of the whole LaTex stuff...) Yes, LyX has that in math_parse.C Dino> - code to render them on screen (possibly in Qt...) LyX has that too. However, the KDE project has something named KFormula that could be very useful too. Dino> - code to produce PostScript. Hmm, Qt does that for you doesn't it? JMarc
Re: LyX components?
On Thu, 10 Feb 2000, Asger K. Alstrup Nielsen wrote: > Right now, we need stability more than the new painter if you ask me. > People say that 1.1.2 was more stable than what we have now. That's > the wrong direction. 1.1.5 should be more stable than 1.1.2! Which is why I haven't sent my PR statement anywhere. At least not till I remove the bits about "most stable ever". Allan. (ARRae)
