Re: Renaming math stream objects

On Sat, 2 Jan 2021 at 17:54, Richard Kimberly Heck wrote: > On 1/2/21 11:33 AM, Thibaut Cuvelier wrote: > > I'm just upping this conversation: can I push the patches to rename the > classes to MathMLStream and TeXMathStream? > > Yes, I think that's fine. > Thanks, I've just pushed the relevant co

Re: Renaming math stream objects

On 1/2/21 11:33 AM, Thibaut Cuvelier wrote: > I'm just upping this conversation: can I push the patches to rename > the classes to MathMLStream and TeXMathStream? Yes, I think that's fine. Riki > > On Mon, 28 Dec 2020 at 20:18, Thibaut Cuvelier > wrote: > > On Mon

Re: Renaming math stream objects

I'm just upping this conversation: can I push the patches to rename the classes to MathMLStream and TeXMathStream? On Mon, 28 Dec 2020 at 20:18, Thibaut Cuvelier wrote: > On Mon, 28 Dec 2020 at 19:33, Jean-Marc Lasgouttes > wrote: > >> Le 26 décembre 2020 20:07:19 GMT+01:00, Thibaut Cuvelier <

Re: Renaming math stream objects

On Mon, 28 Dec 2020 at 19:33, Jean-Marc Lasgouttes wrote: > Le 26 décembre 2020 20:07:19 GMT+01:00, Thibaut Cuvelier < > tcuvel...@lyx.org> a écrit : >> >> Dear list, >> >> In https://www.lyx.org/trac/ticket/12055, there was some confusion about >> the name of the streams used to output math: the

Re: Renaming math stream objects

Le 26 décembre 2020 20:07:19 GMT+01:00, Thibaut Cuvelier a écrit : >Dear list, > >In https://www.lyx.org/trac/ticket/12055, there was some confusion about >the name of the streams used to output math: there is OctaveStream for >Octave, MathematicaStream for Mathematica, etc., but MathStream for M

Re: Renaming frontends/qt4 to frontends/qt ?

Le 23/07/2019 à 01:02, Pavel Sanda a écrit : On Fri, Jul 19, 2019 at 09:19:28PM +0200, Jean-Marc Lasgouttes wrote: Note that It might be that I am wrong, and that git is able to follow this quite well. It is able, but you might need extra params like when searching through log history (eg from

Re: Renaming frontends/qt4 to frontends/qt ?

On Fri, Jul 19, 2019 at 09:19:28PM +0200, Jean-Marc Lasgouttes wrote: > Note that It might be that I am wrong, and that git is able > to follow this quite well. It is able, but you might need extra params like when searching through log history (eg from now you have to git log --follow -p file).

Re: Renaming frontends/qt4 to frontends/qt ?

Le 21/07/2019 à 12:37, Jürgen Spitzmüller a écrit : Am Sonntag, den 21.07.2019, 12:34 +0200 schrieb Jean-Marc Lasgouttes: Can you push please ? Sure, done. The file was only renamed, right? No changes in content? Thanks. That's perfect. JMarc

Re: Renaming frontends/qt4 to frontends/qt ?

Am Sonntag, den 21.07.2019, 12:34 +0200 schrieb Jean-Marc Lasgouttes: > Can you push please ? Sure, done. The file was only renamed, right? No changes in content? Jürgen signature.asc Description: This is a digitally signed message part

Re: Renaming frontends/qt4 to frontends/qt ?

Le 21 juillet 2019 11:33:54 GMT+02:00, "Jürgen Spitzmüller" a écrit : >Am Sonntag, den 21.07.2019, 11:07 +0200 schrieb Jean-Marc Lasgouttes: >> Yes, I did a mv instead of git mv. >> >> Fixed now. > >Did you push? > >Jürgen Probably not :) But I am not home until this evening now. Can you push

Re: Renaming frontends/qt4 to frontends/qt ?

Am Sonntag, den 21.07.2019, 11:07 +0200 schrieb Jean-Marc Lasgouttes: > Yes, I did a mv instead of git mv. > > Fixed now. Did you push? Jürgen signature.asc Description: This is a digitally signed message part

Re: Renaming frontends/qt4 to frontends/qt ?

Le 21/07/2019 à 09:22, Jürgen Spitzmüller a écrit : Am Sonntag, den 21.07.2019, 09:17 +0200 schrieb Jürgen Spitzmüller: Is it possible that you renamed qt4.m4 to qt.m4 and forgot to add the new file? Here, qt4.m4 where the above macro is defined, has been removed without replacement. ... and r

Re: Renaming frontends/qt4 to frontends/qt ?

Am Sonntag, den 21.07.2019, 09:17 +0200 schrieb Jürgen Spitzmüller: > Is it possible that you renamed qt4.m4 to qt.m4 and forgot to add the > new file? Here, qt4.m4 where the above macro is defined, has been > removed without replacement. ... and readding it (renamed) seems to fix building. Jürge

Re: Renaming frontends/qt4 to frontends/qt ?

Am Sonntag, den 21.07.2019, 08:47 +0200 schrieb Jürgen Spitzmüller: > configure now fails for me with: > > ./configure: line 9472: syntax error near unexpected token `4.5.0' > ./configure: line 9472: `QT_DO_IT_ALL(4.5.0)' > > This is after make distclean and ./autogen.sh Is it possible that you

Re: Renaming frontends/qt4 to frontends/qt ?

Am Sonntag, den 21.07.2019, 00:15 +0200 schrieb Jean-Marc Lasgouttes: > I have done it now. configure now fails for me with: ./configure: line 9472: syntax error near unexpected token `4.5.0' ./configure: line 9472: `QT_DO_IT_ALL(4.5.0)' This is after make distclean and ./autogen.sh Jürgen >

Re: Renaming frontends/qt4 to frontends/qt ?

Am Sonntag, 21. Juli 2019, 00:15:57 CEST schrieb Jean-Marc Lasgouttes: > Le 20/07/2019 à 20:35, Kornel Benko a écrit : > >> I think that would be fine and, potentially, save some hassle. > >> > >> Riki > > > > +1 for doing it as soon as possible (now?) > > I will take care for the cmake part. > >

Re: Renaming frontends/qt4 to frontends/qt ?

Le 20/07/2019 à 20:35, Kornel Benko a écrit : I think that would be fine and, potentially, save some hassle. Riki +1 for doing it as soon as possible (now?) I will take care for the cmake part. I have done it now. The cmake part should not be too difficult considering what I had to do. JM

Re: Renaming frontends/qt4 to frontends/qt ?

Am Samstag, 20. Juli 2019, 14:23:05 CEST schrieb Richard Kimberly Heck: > On 7/20/19 1:01 AM, Jürgen Spitzmüller wrote: > > Am Freitag, den 19.07.2019, 21:19 +0200 schrieb Jean-Marc Lasgouttes: > >> It is more and more absurd to have a front end named qt4 these days. > >> What about renaming every

Re: Renaming frontends/qt4 to frontends/qt ?

On 7/20/19 1:01 AM, Jürgen Spitzmüller wrote: > Am Freitag, den 19.07.2019, 21:19 +0200 schrieb Jean-Marc Lasgouttes: >> It is more and more absurd to have a front end named qt4 these days. >> What about renaming everything qt? It looks like a good idea before >> release to ease backport. Note th

Re: Renaming frontends/qt4 to frontends/qt ?

Am Freitag, den 19.07.2019, 21:19 +0200 schrieb Jean-Marc Lasgouttes: > It is more and more absurd to have a front end named qt4 these days. > What about renaming everything qt? It looks like a good idea before > release to ease backport. Note that It might be that I am wrong, and > that git is

Re: Renaming revertedTests

Am Freitag, 4. Dezember 2015 um 11:54:37, schrieb Guenter Milde > On 2015-12-04, Kornel Benko wrote: > > Am 3. Dezember 2015 um 22:08:35, schrieb Guenter Milde > >> On 2015-12-02, Kornel Benko wrote: > >> > Am 2. Dezember 2015 um 22:07:36, schrieb Guenter Milde > >> > > > Dear Kornel, > > >

Re: Renaming revertedTests

On 2015-12-04, Kornel Benko wrote: > Am 3. Dezember 2015 um 22:08:35, schrieb Guenter Milde >> On 2015-12-02, Kornel Benko wrote: >> > Am 2. Dezember 2015 um 22:07:36, schrieb Guenter Milde Dear Kornel, >> Generally, labels are sensible to select subsets that cannot easily be >> selected via r

Re: Renaming revertedTests

On Fri, Dec 04, 2015 at 02:06:57AM +0100, Kornel Benko wrote: > Am Donnerstag, 3. Dezember 2015 um 22:08:35, schrieb Guenter Milde > > > >> >> Do we want a label for all tests with low signal/noise ratio? > > > > >> > I want. > > > > >> >> How to name this label? > > > > >> Suggestions: fragil

Re: Renaming revertedTests

Am Donnerstag, 3. Dezember 2015 um 22:08:35, schrieb Guenter Milde > On 2015-12-02, Kornel Benko wrote: > > Am 2. Dezember 2015 um 22:07:36, schrieb Guenter Milde > > Dear Kornel, > > ... > > >> It would make it easier to work with the labels, if we write the > >> complete "hierarchy" into su

Re: Renaming revertedTests

On 2015-12-02, Kornel Benko wrote: > Am 2. Dezember 2015 um 22:07:36, schrieb Guenter Milde Dear Kornel, ... >> It would make it easier to work with the labels, if we write the >> complete "hierarchy" into sublabels. > Let my last commit settle a little. I try to implement, but only step > by

Re: Renaming revertedTests

Am Mittwoch, 2. Dezember 2015 um 22:07:36, schrieb Guenter Milde > Dear Kornel, > > thank you for the fast reply. :) > On 2015-12-02, Kornel Benko wrote: ... > When I issue > >> #> ctest --print-label, > I get a long list of all existing labels in the ctest-autotests. > > It would make it e

Re: Renaming revertedTests

Dear Kornel, thank you for the fast reply. On 2015-12-02, Kornel Benko wrote: > Am, 2. Dezember 2015 um 12:20:14, schrieb Guenter Milde >> On 2015-12-01, Kornel Benko wrote: ... >> When tagging tests that fail, >> we want tags for >> a) the reason of failure (TexBug, LyxBug, incompatibility,

Re: Renaming revertedTests

Am Mittwoch, 2. Dezember 2015 um 12:20:14, schrieb Guenter Milde > On 2015-12-01, Kornel Benko wrote: > > Am 30. November 2015 um 12:56:22, schrieb Guenter Milde > >> On 2015-11-28, Kornel Benko wrote: > > Thanks for explaining the filter chain. The table in Development.lyx gives > a quite goo

Re: Renaming revertedTests

On 2015-12-01, Kornel Benko wrote: > Am 30. November 2015 um 12:56:22, schrieb Guenter Milde >> On 2015-11-28, Kornel Benko wrote: Thanks for explaining the filter chain. The table in Development.lyx gives a quite good overview. I still believe there is room for improvement in both, the actual t

Re: Renaming revertedTests

Am Montag, 30. November 2015 um 12:56:22, schrieb Guenter Milde > On 2015-11-28, Kornel Benko wrote: > ... > Why do you use a filter chain? Because some filter are more general than others. First filter is the most general. > Wouldn't it be easier to maintain separate filters? > > Currently

Re: Renaming revertedTests

On 2015-11-28, Kornel Benko wrote: > Originally, this file should have regexes to select export combinations > which fail. Therefore the name 'reverted'. Unfortunately, this name is confusing: we revert a commit but invert a test. > Soon we (Scott and I) found, that some tests worked on Scott's

Re: renaming

Abdelrazak Younes wrote: >> Index: CoordCache.h >> === >> --- CoordCache.h(revision 20023) >> +++ CoordCache.h(working copy) >> @@ -130,7 +130,7 @@ >> CoordCacheBase const & getInsets() const { return insets_;

Re: renaming

Alfredo Braunstein wrote: Is there anyone against the following renaming for the sake of consistency (and austerity) ? Index: CoordCache.h === --- CoordCache.h(revision 20023) +++ CoordCache.h(working copy) @@ -130,7

Re: renaming

On Mon, Sep 03, 2007 at 10:32:52PM +0200, Alfredo Braunstein wrote: > Is there anyone against the following renaming for the sake of consistency > (and austerity) ? Not add all. [I have a secret plan wrt to getter/setter naming, and that particular change fits in well...] Andre'

Re: Renaming files

On Mon, Mar 26, 2007 at 06:34:16PM +0200, Jean-Marc Lasgouttes wrote: > > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > Andre> Just a general question: What do people think is a good time to > Andre> rename a bu

Re: Renaming files

Bo Peng wrote: PS: See the archives for the discussion of the *.C -> *.cpp rename. I was going to say this. :-) The conclusion, if any, of those dicussions is that we should do that after the merge of all important branches. If there are not many active branches, I propose that we do it right

Re: Renaming files

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Just a general question: What do people think is a good time to Andre> rename a bunch of files? Immediately after a stable release, Andre> anytime in between, imm

Re: Renaming files

PS: See the archives for the discussion of the *.C -> *.cpp rename. I was going to say this. :-) The conclusion, if any, of those dicussions is that we should do that after the merge of all important branches. If there are not many active branches, I propose that we do it right after beta2. Ch

Re: Renaming files

Abdelrazak Younes wrote: > Andre Poenitz wrote: >> Just a general question: What do people think is a good time to rename a >> bunch of files? Immediately after a stable release, anytime in between, >> immediately before a stable release? >> >> I think I can find good arguments for and against ei

Re: Renaming files

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Just a general question: What do people think is a good time to Andre> rename a bunch of files? Immediately after a stable release, Andre> anytime in between, immediately before a stable release? Andre> I think I can find good argu

Re: Renaming files

Andre Poenitz wrote: Just a general question: What do people think is a good time to rename a bunch of files? Immediately after a stable release, anytime in between, immediately before a stable release? I think I can find good arguments for and against either version... [I want to rename our QF

Re: Renaming i18n file. When?

On Thursday 15 February 2007 11:39:16 am Jean-Marc Lasgouttes wrote: > The patch is one thing, actually moving all the files is another one. > This has the potential of errors, in the name of the files and/or in > the makefiles. I think I'll return to it after the beta. I agree. > JMarc -- Jo

Re: Renaming i18n file. When?

> "José" == José Matos <[EMAIL PROTECTED]> writes: José> That is also to say that I am not opposed to the inclusion of José> the patch since it is simple, it is localized and it has a José> fall-through. The patch is one thing, actually moving all the files is another one. This has the pote

Re: Renaming i18n file. When?

On Thursday 15 February 2007 11:02:10 am Jean-Marc Lasgouttes wrote: > So, shall we do it before or after the first beta? On my list before the first beta is to check that the documentation (README, INSTALL, ...) is up to date before releasing. Today I am busy evaluating exams. :-( But tomor

Re: renaming lfuns

Andre Poenitz <[EMAIL PROTECTED]> writes: | I want to sanitize the names of the lfuns. As the 'minibuffer commands' | should prbably remain stable and I want a close 1:1 mapping betwen the | command strings and the enum names I propose global search and replace | with new enum enams obtained from

Re: Renaming macros

On Mon, Feb 06, 2006 at 09:46:10AM +1030, Beck, Andrew Thomas - BECAT001 wrote: > > >I just had a thought. > > > >Why not give the template a fixed numerb of cells gain. > > > >A LaTeX macro can have at most nine 'regular' arguments, so something > >like eleven fixed cells should do... > > > >An

RE: Renaming macros

Beck, Andrew Thomas - BECAT001 wrote: > I had thought about this, but that would mean that nargs() returned 11 > rather than the actual number of valid arguments. Since one would only > draw the valid arguments, I suspect we would see bugs similar to > issues with the original patch for bug 2060.

RE: Renaming macros

>I just had a thought. > >Why not give the template a fixed numerb of cells gain. > >A LaTeX macro can have at most nine 'regular' arguments, so something >like eleven fixed cells should do... > >Andre' I had thought about this, but that would mean that nargs() returned 11 rather than the actua

Re: Renaming macros

On Sat, Jan 28, 2006 at 01:59:56PM +0100, Georg Baum wrote: > Am Freitag, 27. Januar 2006 03:20 schrieb Beck, Andrew Thomas - BECAT001: > > OK, here is a better formatted patch, preserving encoding etc. Thanks > > for the feedback. The update is still being done in metrics() in the > > same way tha

Re: Renaming macros

Am Montag, 30. Januar 2006 03:49 schrieb Beck, Andrew Thomas - BECAT001: > >> --- text3.C 31 Dec 2005 11:40:32 - 1.323 > >> +++ text3.C 27 Jan 2006 02:06:30 - > >> @@ -1254,10 +1254,10 @@ > >> else { > >> string s = cmd.argument; > >>

Re: Renaming macros

>> --- text3.C 31 Dec 2005 11:40:32 - 1.323 >> +++ text3.C 27 Jan 2006 02:06:30 - >> @@ -1254,10 +1254,10 @@ >> else { >> string s = cmd.argument; >> string const s1 = token(s, ' ', 1); >> - i

Re: Renaming macros

Am Freitag, 27. Januar 2006 03:20 schrieb Beck, Andrew Thomas - BECAT001: > OK, here is a better formatted patch, preserving encoding etc. Thanks > for the feedback. The update is still being done in metrics() in the > same way that the macro expansion was being done previously. I have > changed it

RE: Renaming macros

Title: RE: Renaming macros OK, here is a better formatted patch, preserving encoding etc. Thanks for the feedback. The update is still being done in metrics() in the same way that the macro expansion was being done previously. I have changed it to cast away the const-ness rather than make

Re: Renaming macros

On Thu, Jan 26, 2006 at 07:10:00AM +1030, Beck, Andrew Thomas - BECAT001 wrote: > > Not in metrics. metrics is only there to compute and cache the size of > > an inset. > > > > Provide some 'changeArgs' function or something like that. > > > > Andre' > > I agree metrics is not the place. However

RE: Renaming macros

Beck, Andrew Thomas - BECAT001 wrote: > How do I know when these things have changed? I have essentially added > more cells for the name & number of args to the macrotemplate class, > allowing them to be edited directly, just like the expansion or display > fields of the macro. In my mind, changin

RE: Renaming macros

Andrew> I agree metrics is not the place. However, at some point you Andrew> need to go cycling through all insets to find the macro Andrew> instantiations and call changeArgs(). You need to do this on Andrew> the same kind of basis as updating the expansion - since both Andrew> reflect changes in

Re: Renaming macros

> "Andrew" == "Beck, Andrew Thomas <- BECAT001" <[EMAIL PROTECTED]>> writes: Andrew> I agree metrics is not the place. However, at some point you Andrew> need to go cycling through all insets to find the macro Andrew> instantiations and call changeArgs(). You need to do this on Andrew> the sam

RE: Renaming macros

Beck, Andrew Thomas - BECAT001 wrote: > Here is the patch as it stands. I'd be interested in comments. OK, here you get some. The next time you send a patch please create a unified diff with function names (write diff -up in your .cvsrc) > One issue is that I've made cells_ mutable, which seems

RE: Renaming macros

Title: RE: Renaming macros Here is the patch as it stands. I'd be interested in comments. One issue is that I've made cells_ mutable, which seems dodgy. Another is that the name & numArgs cells in macrotemplate are just normal cells. I think they should be something th

RE: Renaming macros

> Not in metrics. metrics is only there to compute and cache the size of > an inset. > > Provide some 'changeArgs' function or something like that. > > Andre' I agree metrics is not the place. However, at some point you need to go cycling through all insets to find the macro instantiations and c

Re: Renaming macros

On Wed, Jan 25, 2006 at 12:53:50PM +1030, Beck, Andrew Thomas - BECAT001 wrote: > I am working on a patch for 1.4pre to allow renaming of macro > templates and modifying the number of arguments. It all works, except > the case that a macro template has already been instantiated within > the text. S

Re: Renaming README.Win32

Jean-Marc Lasgouttes wrote: > Andre> On Tue, Nov 30, 2004 at 10:29:34AM +0100, Jean-Marc Lasgouttes > Andre> wrote: >>> I would be willing to remove them if I had a good explanation of >>> the trade off involved. I understand they got removed from >>> 1.4.0cvs, but then they used to be a gain when

Re: Renaming README.Win32

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Tue, Nov 30, 2004 at 10:29:34AM +0100, Jean-Marc Lasgouttes Andre> wrote: >> I would be willing to remove them if I had a good explanation of >> the trade off involved. I understand they got removed from >> 1.4.0cvs, but then the

Re: Renaming README.Win32

On Tue, Nov 30, 2004 at 10:29:34AM +0100, Jean-Marc Lasgouttes wrote: > I would be willing to remove them if I had a good explanation of the > trade off involved. I understand they got removed from 1.4.0cvs, but > then they used to be a gain when they got added. Does that mean that > only old compi

Re: Re: Renaming README.Win32

On Tue, Nov 30, 2004 at 09:38:01AM +0100, [EMAIL PROTECTED] wrote: > > That's strange as LyX 1.4.0cvs + kdewin's Qt port compile almost > > out-of-the box on Win2k with Cygwin (gcc 3.3.1 I believe). > > Hmmm... You mean Qt/Win32 GPL? I think so. At least I am fairly sure the undo fix I recently c

Re: Renaming README.Win32

> "Michael" == <[EMAIL PROTECTED]> writes: >> > In order > to compile LyX 1.3.1, you have to remove all "#pragma >> interface" and > "#pragma implementation" lines from the source >> code. >> >> Do we still have such? I thought they had been removed some time >> ago... Michael> Yes, they a

Re: Re: Renaming README.Win32

Andre Poenitz <[EMAIL PROTECTED]> schrieb am 29.11.2004, 20:31:33: > That's strange as LyX 1.4.0cvs + kdewin's Qt port compile almost > out-of-the box on Win2k with Cygwin (gcc 3.3.1 I believe). Hmmm... You mean Qt/Win32 GPL? That would be great news! Actually, I wasn't successful; maybe I shoul

Re: Renaming README.Win32

On Mon, Nov 29, 2004 at 04:22:01PM +0100, [EMAIL PROTECTED] wrote: > > Hello everybody, > > for various reasons, I'm bound to the Windows platform (XP) at present. > > I have been struggling with the compilation of LyX on Windows for some > time That's strange as LyX 1.4.0cvs + kdewin's Qt port

Re: Renaming README.Win32

Hello everybody, for various reasons, I'm bound to the Windows platform (XP) at present. I have been struggling with the compilation of LyX on Windows for some time and I thought you might be interested in an experience report: Cygwin & Qt X11/free & LyX 1.3.1

Re: Renaming README.Win32

"Angus Leeming" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > I have MinSyS installed on a WinXP machine. I guess I could create a > native Windows LyX executable using the gcc toolchain, no? > Yep. The regular mingw distro (gcc etc.) + msys will do. There are instructions for Qt

Re: Renaming README.Win32

Ruurd Reitsma wrote: > "Angus Leeming" <[EMAIL PROTECTED]> wrote in > message news:[EMAIL PROTECTED] >> Edwin Leuven wrote: >> >> Here, 'formal support' means merging changes made by Ruurd to get >> LyX to compile with the half-baked compiler (Borland) that was used >> to compile the qt/win32 libr

Re: Renaming README.Win32

"Angus Leeming" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Edwin Leuven wrote: > > Here, 'formal support' means merging changes made by Ruurd to get LyX to > compile with the half-baked compiler (Borland) that was used to compile > the qt/win32 library provided by Trolltech. Hypo

Re: Renaming README.Win32

Jean-Marc Lasgouttes wrote: Certainly, using it goes against the spirit of Open Source software and we have chosen, therefore, not to provide formal support for Ruurd's port. > > Edwin> I find this statement hypocritical given the exception in LyX's > Edwin> license for xforms which

Re: Renaming README.Win32

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes: Edwin> Angus Leeming wrote: >>> Certainly, using it goes against the spirit of Open Source >>> software and we have chosen, therefore, not to provide formal >>> support f

Re: Renaming README.Win32

> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes: Edwin> Angus Leeming wrote: >> Certainly, using it goes against the spirit of Open Source software >> and we have chosen, therefore, not to provide formal support for >> Ruurd's port. Edwin> I find this statement hypocritical given the exc

Re: Renaming README.Win32

Angus Leeming wrote: Here, 'formal support' means merging changes made by Ruurd to get LyX to compile with the half-baked compiler (Borland) that was used to compile the qt/win32 library provided by Trolltech. Hypocritical or not, that is never going to happen for reasons other than licencing relig

Re: Renaming README.Win32

Edwin Leuven wrote: > Angus Leeming wrote: >> Certainly, using it >> goes against the spirit of Open Source software and we have chosen, >> therefore, not to provide formal support for Ruurd's port. > > I find this statement hypocritical given the exception in LyX's license > for xforms which goe

Re: Renaming README.Win32

Angus Leeming wrote: Certainly, using it goes against the spirit of Open Source software and we have chosen, therefore, not to provide formal support for Ruurd's port. I find this statement hypocritical given the exception in LyX's license for xforms which goes against the spirit of OS as well .

Re: Renaming README.Win32

Jean-Marc Lasgouttes wrote: > Angus> Shouldn't README.Win32 be renamed as README.Cygwin? If we > Angus> want a README.Win32 then how about something like: > > Jean-Marc> Why not, but we should get our facts right. > Or maybe merge the two file in one. I think we should keep them separate. How abo

Re: Renaming README.Win32

Jean-Marc Lasgouttes wrote: > Angus> Shouldn't README.Win32 be renamed as README.Cygwin? > Angus> If we want a README.Win32 then how about something like: > > Why, not, but we should get our facts right. Sure. Thanks for the corrections, but see below. > Angus> Ruurd Reitsma has created a native

Re: Renaming README.Win32

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Shouldn't README.Win32 be renamed as README.Cygwin? If we want Angus> a README.Win32 then how about something like: Jean-Marc> Why not, but we should get our fac

Re: Renaming README.Win32

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Shouldn't README.Win32 be renamed as README.Cygwin? If we want Angus> a README.Win32 then how about something like: Why, not, but we should get our facts right. Angus> Ruurd Reitsma has created a native port of LyX on Win32, using

Re: renaming

Andre Poenitz wrote: >> Can I prepare a patch with those changes? > > I would think so. This is it. Now LyXText::init(bv) does a metrics-lite (i.e. puts width_ = textwidth_ = bv->workWidth() for the top-level LyXText), and there is no access to textwidth_ (now maxwidth) from outside. You set max

Re: renaming

On Sun, Feb 29, 2004 at 01:26:31PM +0100, Alfredo Braunstein wrote: > - what about renaming LyXText::textWidth/textwidth_ to maxWidth_? > wouldn't it be easier to understand? (it would for me at least). Ok. > - I propose also to remove its accessor function (or to make it private), as > it is/sh

Re: Renaming in lyxfont.h

> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: Baruch> Hello, In lyxfont.h there is an include for gettext.h for some Baruch> obscure reason of using enums ON and OFF that might get Baruch> redefined in locale.h OK, I commited a cleanup patch from Baruch's work and mine. Note that thi

Re: Renaming in lyxfont.h

> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: Baruch> Ok, I'm basically half through, the problem now is not the Baruch> LyXFont, but adding gettext.h to the files that need it and Baruch> received it implicitly by including buffer.h I only had this problem with controllers/character

Re: Renaming in lyxfont.h

* Jean-Marc Lasgouttes <[EMAIL PROTECTED]> [010405 11:09]: > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: > > Baruch> This causes that almost any file includes gettext.h > Baruch> implicitly, it wouldn't be that bad, but in my case it forces > Baruch> reordering of header file includ

Re: Renaming in lyxfont.h

> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: Baruch> Hello, In lyxfont.h there is an include for gettext.h for some Baruch> obscure reason of using enums ON and OFF that might get Baruch> redefined in locale.h Ha! I tried to remove it when I rewrote gettext.[Ch], but could not remem

Re: Renaming in lyxfont.h

Baruch Even <[EMAIL PROTECTED]> writes: [why do you set this Mail-Followup-To:...?] | includes. What I want is permission to rename the ON and OFF to FONT_ON | and FONT_OFF, and do this rename wherever needed. ok. -- Lgb