On Mon, 30 Apr 2007, Andre Poenitz wrote:
svn log insets/InsetEnvironment.cpp and manual parse of log messages.
In that case, it'd be enough to place the instructions on how to do it
somewhere.
I think a list is nevertheless a good idea...
I was hoping Bo for instance would have a script
On Mon, 30 Apr 2007, Andre Poenitz wrote:
svn log insets/InsetEnvironment.cpp and manual parse of log messages.
In that case, it'd be enough to place the instructions on how to do it
somewhere.
I think a list is nevertheless a good idea...
I was hoping Bo for instance would have a script
Andre Poenitz wrote:
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
On Windows I have of course only FAT and NTFS, in my case only NTFS.
This 'of course' is a limitation imposed by yourself.
You are going a bit far here :-)
There is no
problem to have e.g. ext2 partitions
On Mon, Apr 30, 2007 at 12:37:44AM +0200, Andre Poenitz wrote:
On Sun, Apr 29, 2007 at 11:50:08PM +0200, Abdelrazak Younes wrote:
Let's please drop this discussion that will get us nowhere. What's done
is done. Andre' is obviously a very competent programmer and he knows
what he is doing.
On Monday 30 April 2007 02:08:10 [EMAIL PROTECTED] wrote:
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include the name before
as well as after).
It would be nice. But notice that there are several stages in the
On Mon, 30 Apr 2007, José Matos wrote:
On Monday 30 April 2007 02:08:10 [EMAIL PROTECTED] wrote:
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include the name before
as well as after).
It would be nice. But notice
On Mon, Apr 30, 2007 at 09:47:20AM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
On Windows I have of course only FAT and NTFS, in my case only NTFS.
This 'of course' is a limitation imposed by yourself.
You are going a bit
On Mon, Apr 30, 2007 at 03:08:10AM +0200, [EMAIL PROTECTED] wrote:
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include the name before
as well as after).
Good idea.
Andre'
On Mon, Apr 30, 2007 at 03:16:33AM +0200, Uwe Stöhr wrote:
SVN was _not_ broken.
First, you need not. svn help mv. URL-URL is the interesting part,
just rename one of the 'offending' files, run 'svn up' and be done.
TortoiseSVN suggested I should cleanup the tree but this doesn't help.
My
On Mon, Apr 30, 2007 at 01:50:56PM +0200, [EMAIL PROTECTED] wrote:
On Mon, 30 Apr 2007, José Matos wrote:
On Monday 30 April 2007 02:08:10 [EMAIL PROTECTED] wrote:
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include
Andre Poenitz wrote:
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
On Windows I have of course only FAT and NTFS, in my case only NTFS.
This 'of course' is a limitation imposed by yourself.
You are going a bit far here :-)
There is no
problem to have e.g. ext2 partitions
On Mon, Apr 30, 2007 at 12:37:44AM +0200, Andre Poenitz wrote:
> On Sun, Apr 29, 2007 at 11:50:08PM +0200, Abdelrazak Younes wrote:
> > Let's please drop this discussion that will get us nowhere. What's done
> > is done. Andre' is obviously a very competent programmer and he knows
> > what he is
On Monday 30 April 2007 02:08:10 [EMAIL PROTECTED] wrote:
> Would it be useful to place list somewhere with the files that were
> renamed and/or merged? (The list should of course include the name before
> as well as after).
It would be nice. But notice that there are several stages in the
On Mon, 30 Apr 2007, José Matos wrote:
On Monday 30 April 2007 02:08:10 [EMAIL PROTECTED] wrote:
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include the name before
as well as after).
It would be nice. But notice
On Mon, Apr 30, 2007 at 09:47:20AM +0200, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote:
> >>On Windows I have of course only FAT and NTFS, in my case only NTFS.
> >
> >This 'of course' is a limitation imposed by yourself.
>
> You are
On Mon, Apr 30, 2007 at 03:08:10AM +0200, [EMAIL PROTECTED] wrote:
> Would it be useful to place list somewhere with the files that were
> renamed and/or merged? (The list should of course include the name before
> as well as after).
Good idea.
Andre'
On Mon, Apr 30, 2007 at 03:16:33AM +0200, Uwe Stöhr wrote:
> >>>SVN was _not_ broken.
>
> >First, you need not. svn help mv. URL->URL is the interesting part,
> >just rename one of the 'offending' files, run 'svn up' and be done.
>
> TortoiseSVN suggested I should cleanup the tree but this
On Mon, Apr 30, 2007 at 01:50:56PM +0200, [EMAIL PROTECTED] wrote:
> On Mon, 30 Apr 2007, José Matos wrote:
>
> >On Monday 30 April 2007 02:08:10 [EMAIL PROTECTED] wrote:
> >>Would it be useful to place list somewhere with the files that were
> >>renamed and/or merged? (The list should of course
I'm very displeased by the renamng actions you did the last week. This was absolutely unnecessary,
we just have released a second beta and our exercise is to fix the remaining bugs to be able to
release LyX 1.5.0.
Sorry, but why did you mean we have to change our complete infrastructure while
Uwe Stöhr wrote:
I'm very displeased by the renamng actions you did the last week. This
was absolutely unnecessary, we just have released a second beta and our
exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
Please calm down Uwe, the renaming was discussed and approved
was to ease maintanance of a stable and a development branch
when basically all files change.
Sorry, but why did you mean we have to change our complete infrastructure
while we are close to a stable release?
Hunt the archive. Doing the renamings _now_ was discussed and approved
by several people. I don't
, just because we are humans and might forget somethig. What is
displeasing me are renamings like LyXServer - Server, there's no real advantage and this could
also be done at the beginning of the LyX 1.6 development.
We now also lost the SVN version history that was very important to be able
Uwe Stöhr schrieb:
We will see. Most of the changes were of the type 'safe if it compiles
afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by Color.h and color.h some
days ago and now again by Layout.h and layout.h. That an example of the problems I
Uwe Stöhr wrote:
Uwe Stöhr schrieb:
We will see. Most of the changes were of the type 'safe if it compiles
afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by
Color.h and color.h some days ago and now again by Layout.h and
layout.h. That an example of the
On Sunday 29 April 2007 18:21:34 Uwe Stöhr wrote:
I'm very displeased by the renamng actions you did the last week. This was
absolutely unnecessary, we just have released a second beta and our
exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
Uwe, this was said before but
On Sun, Apr 29, 2007 at 11:38:58PM +0200, Uwe Stöhr wrote:
Does anybody know this method?
Anybody? Yes, obviously...
But besides this, now also many of the 1.5
patches in Bugzilla have the be rewritten. For me it was not easy to follow
e.g. where for example a patch to tabular.C is to be
On Sun, Apr 29, 2007 at 11:46:17PM +0200, Uwe Stöhr wrote:
Uwe Stöhr schrieb:
We will see. Most of the changes were of the type 'safe if it compiles
afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by
Color.h and color.h some days ago and now again by
On Sun, Apr 29, 2007 at 11:50:08PM +0200, Abdelrazak Younes wrote:
Let's please drop this discussion that will get us nowhere. What's done
is done. Andre' is obviously a very competent programmer and he knows
what he is doing.
I sometimes think I know what I am doing.
But the fact that we
got a
totally broken tree.
On Windows I have of course only FAT and NTFS, in my case only NTFS.
Andre' is obviously a very competent programmer and he knows
what he is doing.
Have I ever said something different?
I just wasn't happy that he didn't thought about all consequences of the renamings
different? I just wasn't happy that he
didn't thought about all consequences of the renamings.
To be precise: I chose not to care too much. I knew that I will be
around all the time, so at worst there's a lag of a few hours in case
something goes wrong until it get fixed. If I'd double checked
Andre Poenitz schrieb:
SVN was _not_ broken.
First, you need not. svn help mv. URL-URL is the interesting part,
just rename one of the 'offending' files, run 'svn up' and be done.
TortoiseSVN suggested I should cleanup the tree but this doesn't help.
My SVN makes lots of troubles and
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include the name before
as well as after).
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
On 4/29/07, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include the name before
as well as after).
About half of my changes are documented in svn log messages.
Bo
SVN was _not_ broken.
I second that. If you have color.h and it renames to Color.h, windows
will complain. You can always remove color.h and 'svn update'. In the
worst case, you can remove the whole source tree and update.
Cheers,
Bo
I'm very displeased by the renamng actions you did the last week. This was absolutely unnecessary,
we just have released a second beta and our exercise is to fix the remaining bugs to be able to
release LyX 1.5.0.
Sorry, but why did you mean we have to change our complete infrastructure while
Uwe Stöhr wrote:
I'm very displeased by the renamng actions you did the last week. This
was absolutely unnecessary, we just have released a second beta and our
exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
Please calm down Uwe, the renaming was discussed and approved
The idea was to ease maintanance of a stable and a development branch
when basically all files change.
> Sorry, but why did you mean we have to change our complete infrastructure
> while we are close to a stable release?
Hunt the archive. Doing the renamings _now_ was discussed and approved
by se
ot;. I mean the dialog
source code merge is error prone, just because we are humans and might forget somethig. What is
displeasing me are renamings like "LyXServer" -> "Server", there's no real advantage and this could
also be done at the beginning of the LyX 1.6 developm
Uwe Stöhr schrieb:
> We will see. Most of the changes were of the type 'safe if it compiles
> afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by "Color.h" and "color.h" some
days ago and now again by "Layout.h" and "layout.h". That an example of the problems
Uwe Stöhr wrote:
Uwe Stöhr schrieb:
> We will see. Most of the changes were of the type 'safe if it compiles
> afterwards'.
I forgot to mention the SVN problems. You blocked the SVN checkout by
"Color.h" and "color.h" some days ago and now again by "Layout.h" and
"layout.h". That an
On Sunday 29 April 2007 18:21:34 Uwe Stöhr wrote:
> I'm very displeased by the renamng actions you did the last week. This was
> absolutely unnecessary, we just have released a second beta and our
> exercise is to fix the remaining bugs to be able to release LyX 1.5.0.
Uwe, this was said before
On Sun, Apr 29, 2007 at 11:38:58PM +0200, Uwe Stöhr wrote:
> Does anybody know this method?
"Anybody"? Yes, obviously...
> But besides this, now also many of the 1.5
> patches in Bugzilla have the be rewritten. For me it was not easy to follow
> e.g. where for example a patch to tabular.C is
On Sun, Apr 29, 2007 at 11:46:17PM +0200, Uwe Stöhr wrote:
> Uwe Stöhr schrieb:
>
> > > We will see. Most of the changes were of the type 'safe if it compiles
> > > afterwards'.
>
> I forgot to mention the SVN problems. You blocked the SVN checkout by
> "Color.h" and "color.h" some days ago and
On Sun, Apr 29, 2007 at 11:50:08PM +0200, Abdelrazak Younes wrote:
> Let's please drop this discussion that will get us nowhere. What's done
> is done. Andre' is obviously a very competent programmer and he knows
> what he is doing.
I sometimes think I know what I am doing.
But the fact that
't thought about all consequences of the renamings. I hope you can
understand that I'm not very happy as I have three times this week to check out the sources
completely to a new tree because it was broken after SVN checkout trys.
I think we can close this discussion now as it was not my intention
iously a very competent programmer and he knows what
> >> he is doing.
>
> Have I ever said something different? I just wasn't happy that he
> didn't thought about all consequences of the renamings.
To be precise: I chose not to care too much. I knew that I will be
around all the t
Andre Poenitz schrieb:
SVN was _not_ broken.
First, you need not. svn help mv. URL->URL is the interesting part,
just rename one of the 'offending' files, run 'svn up' and be done.
TortoiseSVN suggested I should cleanup the tree but this doesn't help.
My SVN makes lots of troubles and
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include the name before
as well as after).
/Christian
--
Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
On 4/29/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Would it be useful to place list somewhere with the files that were
renamed and/or merged? (The list should of course include the name before
as well as after).
About half of my changes are documented in svn log messages.
Bo
>>> SVN was _not_ broken.
I second that. If you have color.h and it renames to Color.h, windows
will complain. You can always remove color.h and 'svn update'. In the
worst case, you can remove the whole source tree and update.
Cheers,
Bo
So... definitely a step in the right direction.
I've a few issues left:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of course this mean
2. rowpainter.cpp is all about a class
On Thursday 26 April 2007 8:29:43 am Andre Poenitz wrote:
So... definitely a step in the right direction.
I've a few issues left:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of course this mean
2. rowpainter.cpp is all about a class RowPainter, which is used only
locally, so it does not show up in the .h. I'd
Andre Poenitz wrote:
So... definitely a step in the right direction.
I've a few issues left:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of course this mean
2. rowpainter.cpp
On Thu, Apr 26, 2007 at 08:05:56AM -0500, Bo Peng wrote:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of course this mean
2. rowpainter.cpp is all about a class RowPainter, which is
On Thu, Apr 26, 2007 at 03:33:45PM +0200, Stephan Witt wrote:
Andre Poenitz wrote:
So... definitely a step in the right direction.
I've a few issues left:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something
Andre Poenitz wrote:
On Thu, Apr 26, 2007 at 03:33:45PM +0200, Stephan Witt wrote:
Andre Poenitz wrote:
So... definitely a step in the right direction.
I've a few issues left:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/
So... definitely a step in the right direction.
I've a few issues left:
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of course this mean
2. rowpainter.cpp is all about a class
On Thursday 26 April 2007 8:29:43 am Andre Poenitz wrote:
> So... definitely a step in the right direction.
>
> I've a few issues left:
>
> 1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
>I mean, it is clear that 'LyXLayout' in src/ has something todo with
>LyX, isn't
1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
I mean, it is clear that 'LyXLayout' in src/ has something todo with
LyX, isn't it. Of course this mean
2. rowpainter.cpp is all about a class RowPainter, which is used only
locally, so it does not show up in the .h. I'd
Andre Poenitz wrote:
> So... definitely a step in the right direction.
>
> I've a few issues left:
>
> 1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
>I mean, it is clear that 'LyXLayout' in src/ has something todo with
>LyX, isn't it. Of course this mean
>
> 2.
On Thu, Apr 26, 2007 at 08:05:56AM -0500, Bo Peng wrote:
> >1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
> > I mean, it is clear that 'LyXLayout' in src/ has something todo with
> > LyX, isn't it. Of course this mean
> >
> >2. rowpainter.cpp is all about a class
On Thu, Apr 26, 2007 at 03:33:45PM +0200, Stephan Witt wrote:
> Andre Poenitz wrote:
> > So... definitely a step in the right direction.
> >
> > I've a few issues left:
> >
> > 1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
> >I mean, it is clear that 'LyXLayout' in src/
Andre Poenitz wrote:
> On Thu, Apr 26, 2007 at 03:33:45PM +0200, Stephan Witt wrote:
>> Andre Poenitz wrote:
>>> So... definitely a step in the right direction.
>>>
>>> I've a few issues left:
>>>
>>> 1. I'd like to get rid of the 'LyX'/'L' prefix whenever possible.
>>>I mean, it is clear that
Bernhard == Bernhard Roider [EMAIL PROTECTED] writes:
Bernhard I remember that .cc is often used instead of .cpp or .C (at
Bernhard least in linux?)
Here is what the C++ FAQ has to say:
http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.8
Basically: If you already have a
I just renamed the .ui files. This was straightforward. However, the
stuff in qt4/* is harder as there'll be clashes with headers in src/*.h.
So I'd keep it as it is at the moment and rather merge QFooDialog.[Ch]
into QFoo.[Ch] whenever it makes sense.
The dependencies are pretty strong
On Tue, Apr 24, 2007 at 11:14:03AM +0200, Andre Poenitz wrote:
I just renamed the .ui files. This was straightforward. However, the
stuff in qt4/* is harder as there'll be clashes with headers in src/*.h.
So I'd keep it as it is at the moment and rather merge QFooDialog.[Ch]
into
Andre Poenitz wrote:
I just renamed the .ui files. This was straightforward. However, the
stuff in qt4/* is harder as there'll be clashes with headers in
src/*.h.
So I'd keep it as it is at the moment and rather merge
QFooDialog.[Ch] into QFoo.[Ch] whenever it makes sense.
The dependencies
this would be non-mechanical,
i.e. post-1.5.0 stuff.
The main reason for the renamings _now_ was that patches later will
easier apply to 1.5.x and 1.6.x-svn.
Or FooWidget? I'd like to get rid of the QDialog inheritance and switch
to QWidget for all dialogs (so that it can be embedded in other
into one file. I have
Andre not thought too much about the latter, in any case this would
Andre be non-mechanical, i.e. post-1.5.0 stuff.
Andre The main reason for the renamings _now_ was that patches later
Andre will easier apply to 1.5.x and 1.6.x-svn.
+1
JMarc
On Tuesday 24 April 2007 11:07:04 am Jean-Marc Lasgouttes wrote:
Andre The main reason for the renamings _now_ was that patches later
Andre will easier apply to 1.5.x and 1.6.x-svn.
+1
That is the single reason to do it now. :-)
JMarc
--
José Abílio
the latter, in any case this would be non-mechanical,
i.e. post-1.5.0 stuff.
The main reason for the renamings _now_ was that patches later will
easier apply to 1.5.x and 1.6.x-svn.
OK.
Or FooWidget? I'd like to get rid of the QDialog inheritance and switch
to QWidget for all dialogs (so
s/QBox.C/Box.C/g
s/QBox.h/Box.h/g
Andre,
I find a serious problem with these renames. First, it does not follow
our policy that class name matching file name. Second, these changes
lead to co-existence of src/Box.h and src/frontends/qt4/Box.h etc, and
#include Box.h may lead to error.
Bo
-existence of src/Box.h and src/frontends/qt4/Box.h etc, and
#include Box.h may lead to error.
That's one of the reasons I postponed these renamings.
Andre'
> "Bernhard" == Bernhard Roider <[EMAIL PROTECTED]> writes:
Bernhard> I remember that .cc is often used instead of .cpp or .C (at
Bernhard> least in linux?)
Here is what the C++ FAQ has to say:
http://www.parashift.com/c++-faq-lite/coding-standards.html#faq-27.8
Basically: "If you already
I just renamed the .ui files. This was straightforward. However, the
stuff in qt4/* is harder as there'll be clashes with headers in src/*.h.
So I'd keep it as it is at the moment and rather merge QFooDialog.[Ch]
into QFoo.[Ch] whenever it makes sense.
The dependencies are pretty strong
On Tue, Apr 24, 2007 at 11:14:03AM +0200, Andre Poenitz wrote:
>
> I just renamed the .ui files. This was straightforward. However, the
> stuff in qt4/* is harder as there'll be clashes with headers in src/*.h.
>
> So I'd keep it as it is at the moment and rather merge QFooDialog.[Ch]
> into
Andre Poenitz wrote:
I just renamed the .ui files. This was straightforward. However, the
stuff in qt4/* is harder as there'll be clashes with headers in
src/*.h.
So I'd keep it as it is at the moment and rather merge
QFooDialog.[Ch] into QFoo.[Ch] whenever it makes sense.
The dependencies
ht
too much about the latter, in any case this would be non-mechanical,
i.e. post-1.5.0 stuff.
The main reason for the renamings _now_ was that patches later will
easier apply to 1.5.x and 1.6.x-svn.
> Or FooWidget? I'd like to get rid of the QDialog inheritance and switch
> to QWidget f
uot; or "merging the two classes"?
Andre> Right now I mean "putting two classes into one file". I have
Andre> not thought too much about the latter, in any case this would
Andre> be non-mechanical, i.e. post-1.5.0 stuff.
Andre> The main reason for the renamings _now_ was that patches later
Andre> will easier apply to 1.5.x and 1.6.x-svn.
+1
JMarc
On Tuesday 24 April 2007 11:07:04 am Jean-Marc Lasgouttes wrote:
> Andre> The main reason for the renamings _now_ was that patches later
> Andre> will easier apply to 1.5.x and 1.6.x-svn.
>
> +1
That is the single reason to do it now. :-)
> JMarc
--
José Abílio
;. I have not thought
too much about the latter, in any case this would be non-mechanical,
i.e. post-1.5.0 stuff.
The main reason for the renamings _now_ was that patches later will
easier apply to 1.5.x and 1.6.x-svn.
OK.
Or FooWidget? I'd like to get rid of the QDialog inheritance and switch
s/QBox.C/Box.C/g
s/QBox.h/Box.h/g
Andre,
I find a serious problem with these renames. First, it does not follow
our policy that class name matching file name. Second, these changes
lead to co-existence of src/Box.h and src/frontends/qt4/Box.h etc, and
#include "Box.h" may lead to error.
Bo
ly
> Second, these changes
> lead to co-existence of src/Box.h and src/frontends/qt4/Box.h etc, and
> #include "Box.h" may lead to error.
That's one of the reasons I postponed these renamings.
Andre'
On Sun, 22 Apr 2007, Bo Peng wrote:
I am thinking about something like s/QL//g and s/Q//g in
src/frontends/qt4.
And all .C to .cpp?
Why? (I don't remember a consesus for that, but then again I'm lazy as I
don't go and look...)
/C
--
Christian Ridderström, +46-8-768 39 44
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Just to make sure: Did we kind of agree some time ago that
Andre 'after beta 2' was a good time to rename classes and files?
Andre I am thinking about something like s/QL//g and s/Q//g in
Andre src/frontends/qt4.
Note that we have to be
On Mon, Apr 23, 2007 at 10:51:55AM +0200, [EMAIL PROTECTED] wrote:
I am thinking about something like s/QL//g and s/Q//g in
src/frontends/qt4.
And all .C to .cpp?
Why? (I don't remember a consesus for that, but then again I'm lazy as I
don't go and look...)
Consensus was along the
On Mon, Apr 23, 2007 at 11:07:43AM +0200, Jean-Marc Lasgouttes wrote:
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Just to make sure: Did we kind of agree some time ago that
Andre 'after beta 2' was a good time to rename classes and files?
Andre I am thinking about something
Complain now or never:
s/LyXKeySymFactory.C/KeySymFactory.C/g
s/QAbout.C/About.C/g
s/QAbout.h/About.h/g
s/QAboutDialog.C/AboutDialog.C/g
s/QAboutDialog.h/AboutDialog.h/g
s/QBibitem.C/Bibitem.C/g
s/QBibitem.h/Bibitem.h/g
s/QBibitemDialog.C/BibitemDialog.C/g
s/QBibitemDialog.h/BibitemDialog.h/g
Andre Poenitz wrote:
On Mon, Apr 23, 2007 at 10:51:55AM +0200, [EMAIL PROTECTED] wrote:
I am thinking about something like s/QL//g and s/Q//g in
src/frontends/qt4.
And all .C to .cpp?
Why? (I don't remember a consesus for that, but then again I'm lazy as I
don't go and look...)
Consensus
On Mon, 23 Apr 2007, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Mon, Apr 23, 2007 at 10:51:55AM +0200,
[EMAIL PROTECTED] wrote:
I am thinking about something like s/QL//g and s/Q//g in
src/frontends/qt4.
And all .C to .cpp?
Why? (I don't remember a consesus for that,
On Mon, 23 Apr 2007 11:18:45 +0200
Andre Poenitz [EMAIL PROTECTED] wrote:
On Mon, Apr 23, 2007 at 10:51:55AM +0200, [EMAIL PROTECTED] wrote:
I am thinking about something like s/QL//g and s/Q//g in
src/frontends/qt4.
And all .C to .cpp?
Why? (I don't remember a consesus for
On Monday 23 April 2007 12:26:51 pm [EMAIL PROTECTED] wrote:
Guess I'm in the 'don't care' camp. The only advantage I can think of for
.C is that you can then do e.g.
ls Dialog.[Ch]
That is easier to write than
ls Dialog.{cpp,h}
But not by much. :-)
/Christian
--
José Abílio
On Mon, Apr 23, 2007 at 03:06:36PM +0300, Martin Vermeer wrote:
I remember being opposed. .cpp, .hpp is a windowsism.
So how 'opposed' are you?
Andre'
On 4/23/07, Andre Poenitz [EMAIL PROTECTED] wrote:
On Mon, Apr 23, 2007 at 03:06:36PM +0300, Martin Vermeer wrote:
I remember being opposed. .cpp, .hpp is a windowsism.
Yeap. One of the problems with .C is that .c and .C are the same under
windows, and caused some trouble in scons (which I
And standardization of lyxfunc, lyx_cb etc?
By this I mean:
LyXAction
lyx_cb
lyxfind
lyxgluelength
lyxtextclasslist
cursor_slice
to
LyxAction
LyxCB (what is cb?)
LyxFind
LyxGlueLength
LyxTextClassList
CursorSlice
or
lyx_action
lyx_cb
lyx_find
lyx_glue_length
lyx_textclasslist
cursor_slice
Bo Peng wrote:
And standardization of lyxfunc, lyx_cb etc?
By this I mean:
LyXAction
lyx_cb
lyxfind
lyxgluelength
lyxtextclasslist
cursor_slice
to
LyxAction
LyxCB (what is cb?)
This should eventually go in 1.6.
LyxFind
LyxGlueLength
LyxTextClassList
CursorSlice
or
lyx_action
lyx_cb
On Monday 23 April 2007 3:59:48 pm Bo Peng wrote:
LyxCB (what is cb?)
Callback, this has been in the code since (at least) version 0.5. :-)
--
José Abílio
On Mon, 23 Apr 2007 15:53:32 +0200
Andre Poenitz [EMAIL PROTECTED] wrote:
On Mon, Apr 23, 2007 at 03:06:36PM +0300, Martin Vermeer wrote:
I remember being opposed. .cpp, .hpp is a windowsism.
So how 'opposed' are you?
Andre'
Hmmm... I am just in the mood to be opposed. If there is a
On Mon, 23 Apr 2007 07:50:39 -0700
Bo Peng [EMAIL PROTECTED] wrote:
On 4/23/07, Andre Poenitz [EMAIL PROTECTED] wrote:
On Mon, Apr 23, 2007 at 03:06:36PM +0300, Martin Vermeer wrote:
I remember being opposed. .cpp, .hpp is a windowsism.
Yeap. One of the problems with .C is that .c and .C
1 - 100 of 176 matches
Mail list logo
