Re: List of renamings and merges? (Was:....)
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 or something from which I could create such a list. (He only had for half I think). So I suspect it's more work than it's worth at the moment. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: List of renamings and merges? (Was:....)
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 or something from which I could create such a list. (He only had for half I think). So I suspect it's more work than it's worth at the moment. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Stop the renamings now!!! was: More file/class name changes?
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 under Windows (and about a dozen other filesystems for that matter). I haven't actually tried, but I'd expect that you can even have ext2 within a _file_ using the Deamon tools or such, so you'd probably not even need a partition for that. Not a realistic option... Abdel.
Re: Stop the renamings now!!! was: More file/class name changes?
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. I sometimes think I know what I am doing. But the fact that we run into problems when doing trivial changes to file names is a sign that the LyX naming scheme _was_ a mess so far. It's much, much better now, and it is surely worth the week we 'sacrified' here. I must agree here, though I do see the problems too caused by the rename. But you cannot make an omelet without breaking eggs. I expect it will be much easier now for newcomers to get into the logic of the code. Don't underestimate that -- it will earn us back the lost week. - Martin
Re: List of renamings and merges? (Was:....)
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 transformation, that is several files were renamed several times. /Christian -- José Abílio
Re: List of renamings and merges? (Was:....)
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 that there are several stages in the transformation, that is several files were renamed several times. I don't suppose it's possible to get this information from SVN? In that case, it'd be enough to place the instructions on how to do it somewhere. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Stop the renamings now!!! was: More file/class name changes?
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 far here :-) I thought we were in 'going-too-far-mode'. Andre'
Re: List of renamings and merges? (Was:....)
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'
Re: Stop the renamings now!!! was: More file/class name changes?
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 hammer suggested I should drive a nail into that broken vase but this doesn't help. My SVN makes lots of troubles and after a checkout try I got a totally broken tree. [Just because TortoiseSVN bails out doesn't mean you have a broken SVN tree... Anyway...] If TortoiseSVN fails to checkout the tree is broken for me as result. If the hammer fails to fix the vase the world is broken. On Windows I have of course only FAT and NTFS, in my case only NTFS. This 'of course' is a limitation imposed by yourself. There is no problem to have e.g. ext2 partitions under Windows... Come on, NTFS and FAT is used by all Win systems as standard so there's no discussion that we have to take care of them. Come on, hammers is what I get when I buy 'Set Of Hammer 2003'. There's no discussion that a toolchest should contain anything else than hammers. 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. See above. I doubt your tree was actually broken. However, I understand you are not happy that it did not work out-of-the-box _twice_ this week. But you don't care about my problem, you just broke (tell it as you like) it again with Text.cpp. I mean you know the problematic but still don't check if a renaming leads to two files with the same name. Checking this could not be that difficult. At no time there where two files with the same name in svn. Andre'
Re: List of renamings and merges? (Was:....)
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 the name before as well as after). It would be nice. But notice that there are several stages in the transformation, that is several files were renamed several times. I don't suppose it's possible to get this information from SVN? 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... Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
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 under Windows (and about a dozen other filesystems for that matter). I haven't actually tried, but I'd expect that you can even have ext2 within a _file_ using the Deamon tools or such, so you'd probably not even need a partition for that. Not a realistic option... Abdel.
Re: Stop the renamings now!!! was: More file/class name changes?
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. > > I sometimes think I know what I am doing. > > But the fact that we run into problems when doing trivial changes to > file names is a sign that the LyX naming scheme _was_ a mess so far. > It's much, much better now, and it is surely worth the week we > 'sacrified' here. I must agree here, though I do see the problems too caused by the rename. But you cannot make an omelet without breaking eggs. I expect it will be much easier now for newcomers to get into the logic of the code. Don't underestimate that -- it will earn us back the lost week. - Martin
Re: List of renamings and merges? (Was:....)
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 transformation, that is several files were renamed several times. > /Christian -- José Abílio
Re: List of renamings and merges? (Was:....)
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 that there are several stages in the transformation, that is several files were renamed several times. I don't suppose it's possible to get this information from SVN? In that case, it'd be enough to place the instructions on how to do it somewhere. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Stop the renamings now!!! was: More file/class name changes?
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 far here :-) I thought we were in 'going-too-far-mode'. Andre'
Re: List of renamings and merges? (Was:....)
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'
Re: Stop the renamings now!!! was: More file/class name changes?
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 hammer suggested I should drive a nail into that broken vase but this doesn't help. > >>My SVN makes lots of troubles and after a checkout try I got a totally > >>broken tree. > > > >[Just because TortoiseSVN bails out doesn't mean you have a broken SVN > >tree... Anyway...] > > If TortoiseSVN fails to checkout the tree is broken for me as result. If the hammer fails to fix the vase the world is broken. > >>On Windows I have of course only FAT and NTFS, in my case only NTFS. > > > >This 'of course' is a limitation imposed by yourself. There is no > >problem to have e.g. ext2 partitions under Windows... > > Come on, NTFS and FAT is used by all Win systems as standard so there's no > discussion that we have to take care of them. Come on, hammers is what I get when I buy 'Set Of Hammer 2003'. There's no discussion that a toolchest should contain anything else than hammers. > >>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. > > > >See above. I doubt your tree was actually broken. However, I understand > >you are not happy that it did not work out-of-the-box _twice_ this week. > > But you don't care about my problem, you just "broke" (tell it as you like) > it again with "Text.cpp". > I mean you know the problematic but still don't check if a renaming leads > to two files with the same name. Checking this could not be that difficult. At no time there where two files with the same name in svn. Andre'
Re: List of renamings and merges? (Was:....)
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 the name > >>before > >>as well as after). > > > > It would be nice. But notice that there are several stages in the > >transformation, that is several files were renamed several times. > > I don't suppose it's possible to get this information from SVN? 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... Andre'
Stop the renamings now!!! was: More file/class name changes?
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 we are close to a stable release? Of course the renaming .C - .cpp might have advantages and the merging is in general also a good idea but wasn't that pressing. There was no need to change this at this state of development. Further renaming can be done as soon as a LyX 1.6 development trunk has been created. I'm sure that we have introduced new bugs and problems - the third beta will tell. I the meantime I faced lots of compile problems so that we lost one week of development as our mst active bug fixers couldn't work. We now also lost the SVN version history that was very important to be able to fix bugs. So stop these actions now! If you really can't wait and want to do further renaming, discuss this and create a new brach where you can play if necessary. best regards Uwe
Re: Stop the renamings now!!! was: More file/class name changes?
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 by a majority. You should have been more vocal _before_ the fact. The process is mostly done now and I personally thank Andre' and Bo for leading the change. I reviewed all the renaming commits and I am quite confident that they did not introduce any bugs. Abdel.
Re: Stop the renamings now!!! was: More file/class name changes?
On Sun, Apr 29, 2007 at 07:21:34PM +0200, 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. 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 several people. I don't remember your opposition, but memory is failing me more often than I wish... Of course the renaming .C - .cpp might have advantages and the merging is in general also a good idea but wasn't that pressing. There was no need to change this at this state of development. Further renaming can be done as soon as a LyX 1.6 development trunk has been created. If the renamining had been done in early 1.6.0, no 1.6.0 patach would have been applicable to 1.5.x and vice versa. I'm sure that we have introduced new bugs and problems - the third beta will tell. We will see. Most of the changes were of the type 'safe if it compiles afterwards'. I the meantime I faced lots of compile problems so that we lost one week of development as our mst active bug fixers couldn't work. We now also lost the SVN version history that was very important to be able to fix bugs. The history is not lost, it's just more difficult to access (which is not nice, but certainly not critical). To see the old paragraph.C related messages up to revision 16000 type svn log svn+ssh://[EMAIL PROTECTED]/lyx/lyx-devel/trunk/src/[EMAIL PROTECTED] [of course you might need to adjust the 'poenitz' or guess my password. The first option might be less work...] So stop these actions now! If you really can't wait and want to do further renaming, discuss this and create a new brach where you can play if necessary. You miss the point and I see no reason to stop at a point where more than 90% of the work is done. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
I'm sure that we have introduced new bugs and problems - the third beta will tell. We will see. Most of the changes were of the type 'safe if it compiles afterwards'. There is a difference between it compiles and it works without any bugs. 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 development. We now also lost the SVN version history that was very important to be able to fix bugs. The history is not lost, it's just more difficult to access Does anybody know this method? 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 applied now. You are right that I should have been shout before these actions but it wasn't clear to me that not simply the file were renamed fron .C - .cpp. This change is OK as this can be followed easily, the problem are the file merges and the file and variable renamings. regards Uwe
Re: Stop the renamings now!!! was: More file/class name changes?
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 mentioned. Can't you ceck that you don't break the SVN system with your changes? regards Uwe
Re: Stop the renamings now!!! was: More file/class name changes?
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 problems I mentioned. Can't you ceck that you don't break the SVN system with your changes? Uwe, this has nothing to do with SVN but with case insensitive file systems (i.e. windows). 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. Abdel.
Re: Stop the renamings now!!! was: More file/class name changes?
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 I will say it again. This operation was necessary at this time for the reasons already given by Abdel, André and Michael: - to ease the transition to 1.6; - take into account the different platforms where lyx is developed and used; - to simply the search of the lyx code. Not only that but the process has been very smooth compared with the task at hand. I am happy with the discussion flux during this week. The developers responsible for the rename are aware of this issue and they have balanced their actions. I am satisfied with the whole result and I am sure that this will ease the release of a stable 1.5.0. -- José Abílio
Re: Stop the renamings now!!! was: More file/class name changes?
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 applied now. insets/InsetTabular.cpp But considering that only people more or less familiar with the tabular code would apply that patch and those people are aware of the relationship of tabular.[Ch] and insettabular.[Ch] I don't think that adjusting this particular patch would be a challenge. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
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 Layout.h and layout.h. That an example of the problems I mentioned. Can't you ceck that you don't break the SVN system with your changes? SVN was _not_ broken. Face it. In fact, you could even manage files with 'case problems' under Windows, and you could even _work_ with them if you really wanted. Not on NTFS or FAT, of course. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
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 run into problems when doing trivial changes to file names is a sign that the LyX naming scheme _was_ a mess so far. It's much, much better now, and it is surely worth the week we 'sacrified' here. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
SVN was _not_ broken. Face it. In fact, you could even manage files with 'case problems' under Windows, and you could even _work_ with them if you really wanted. Not on NTFS or FAT, of course. Hä? I couldn't check out/in anything. My SVN makes lots of troubles and after a checkout try I 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. 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 to begin personal flame wars. My intention was to lead to focus back to bug fixing than to more renaming actions. regards Uwe
Re: Stop the renamings now!!! was: More file/class name changes?
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote: SVN was _not_ broken. Face it. In fact, you could even manage files with 'case problems' under Windows, and you could even _work_ with them if you really wanted. Not on NTFS or FAT, of course. Hä? I couldn't check out/in anything. 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. Second, you could if you wanted to. See below. My SVN makes lots of troubles and after a checkout try I got a totally broken tree. [Just because TortoiseSVN bails out doesn't mean you have a broken SVN tree... Anyway...] On Windows I have of course only FAT and NTFS, in my case only NTFS. This 'of course' is a limitation imposed by yourself. There is no problem to have e.g. ext2 partitions under Windows (and about a dozen other filesystems for that matter). I haven't actually tried, but I'd expect that you can even have ext2 within a _file_ using the Deamon tools or such, so you'd probably not even need a partition for that. 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. 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 every single rename by starting with a clean tree I/we would not have been able to finish within a week. Having everything in a big commit would not have worked either as there had been several substantial changes outside that would have broken the 'single shot rename'. 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. See above. I doubt your tree was actually broken. However, I understand you are not happy that it did not work out-of-the-box _twice_ this week. I think we can close this discussion now as it was not my intention to begin personal flame wars. My intention was to lead to focus back to bug fixing than to more renaming actions. I have no problems with personal flame wars as long as the technical issues are stated correctly. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
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 after a checkout try I got a totally broken tree. [Just because TortoiseSVN bails out doesn't mean you have a broken SVN tree... Anyway...] If TortoiseSVN fails to checkout the tree is broken for me as result. On Windows I have of course only FAT and NTFS, in my case only NTFS. This 'of course' is a limitation imposed by yourself. There is no problem to have e.g. ext2 partitions under Windows... Come on, NTFS and FAT is used by all Win systems as standard so there's no discussion that we have to take care of them. 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. See above. I doubt your tree was actually broken. However, I understand you are not happy that it did not work out-of-the-box _twice_ this week. But you don't care about my problem, you just broke (tell it as you like) it again with Text.cpp. I mean you know the problematic but still don't check if a renaming leads to two files with the same name. Checking this could not be that difficult. regards Uwe
List of renamings and merges? (Was:....)
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
Re: List of renamings and merges? (Was:....)
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
Re: Stop the renamings now!!! was: More file/class name changes?
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
Stop the renamings now!!! was: More file/class name changes?
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 we are close to a stable release? Of course the renaming .C -> .cpp might have advantages and the merging is in general also a good idea but wasn't that pressing. There was no need to change this at this state of development. Further renaming can be done as soon as a LyX 1.6 development trunk has been created. I'm sure that we have introduced new bugs and problems - the third beta will tell. I the meantime I faced lots of compile problems so that we lost one week of development as our mst active bug fixers couldn't work. We now also lost the SVN version history that was very important to be able to fix bugs. So stop these actions now! If you really can't wait and want to do further renaming, discuss this and create a new brach where you can play if necessary. best regards Uwe
Re: Stop the renamings now!!! was: More file/class name changes?
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 by a majority. You should have been more vocal _before_ the fact. The process is mostly done now and I personally thank Andre' and Bo for leading the change. I reviewed all the renaming commits and I am quite confident that they did not introduce any bugs. Abdel.
Re: Stop the renamings now!!! was: More file/class name changes?
On Sun, Apr 29, 2007 at 07:21:34PM +0200, 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. 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 several people. I don't remember your opposition, but memory is failing me more often than I wish... > Of course the renaming .C -> .cpp > might have advantages and the merging is in general also a good idea but > wasn't that pressing. There was no need to change this at this state of > development. Further renaming can be done as soon as a LyX 1.6 development > trunk has been created. If the renamining had been done in early 1.6.0, no 1.6.0 patach would have been applicable to 1.5.x and vice versa. > I'm sure that we have introduced new bugs and problems - the third beta > will tell. We will see. Most of the changes were of the type 'safe if it compiles afterwards'. > I the meantime I faced lots of compile problems so that we lost one week of > development as our mst active bug fixers couldn't work. We now also lost > the SVN version history that was very important to be able to fix bugs. The history is not lost, it's just more difficult to access (which is not nice, but certainly not critical). To see the old paragraph.C related messages up to revision 16000 type svn log svn+ssh://[EMAIL PROTECTED]/lyx/lyx-devel/trunk/src/[EMAIL PROTECTED] [of course you might need to adjust the 'poenitz' or guess my password. The first option might be less work...] > So stop these actions now! If you really can't wait and want to do further > renaming, discuss this and create a new brach where you can play if > necessary. You miss the point and I see no reason to stop at a point where more than 90% of the work is done. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
>> I'm sure that we have introduced new bugs and problems - the third beta >> will tell. > > We will see. Most of the changes were of the type 'safe if it compiles > afterwards'. There is a difference between "it compiles" and "it works without any bugs". 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 development. >> We now also lost the SVN version history that was very important to be able to fix bugs. > > The history is not lost, it's just more difficult to access Does anybody know this method? 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 applied now. You are right that I should have been shout before these actions but it wasn't clear to me that not simply the file were renamed fron .C -> .cpp. This change is OK as this can be followed easily, the problem are the file merges and the file and variable renamings. regards Uwe
Re: Stop the renamings now!!! was: More file/class name changes?
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 mentioned. Can't you ceck that you don't break the SVN system with your changes? regards Uwe
Re: Stop the renamings now!!! was: More file/class name changes?
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 problems I mentioned. Can't you ceck that you don't break the SVN system with your changes? Uwe, this has nothing to do with SVN but with case insensitive file systems (i.e. windows). 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. Abdel.
Re: Stop the renamings now!!! was: More file/class name changes?
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 I will say it again. This operation was necessary at this time for the reasons already given by Abdel, André and Michael: - to ease the transition to 1.6; - take into account the different platforms where lyx is developed and used; - to simply the search of the lyx code. Not only that but the process has been very smooth compared with the task at hand. I am happy with the discussion flux during this week. The developers responsible for the rename are aware of this issue and they have balanced their actions. I am satisfied with the whole result and I am sure that this will ease the release of a stable 1.5.0. -- José Abílio
Re: Stop the renamings now!!! was: More file/class name changes?
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 applied now. insets/InsetTabular.cpp But considering that only people more or less familiar with the tabular code would apply that patch and those people are aware of the relationship of tabular.[Ch] and insettabular.[Ch] I don't think that adjusting this particular patch would be a challenge. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
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 "Layout.h" and > "layout.h". That an example of the problems I mentioned. Can't you ceck > that you don't break the SVN system with your changes? SVN was _not_ broken. Face it. In fact, you could even manage files with 'case problems' under Windows, and you could even _work_ with them if you really wanted. Not on NTFS or FAT, of course. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
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 run into problems when doing trivial changes to file names is a sign that the LyX naming scheme _was_ a mess so far. It's much, much better now, and it is surely worth the week we 'sacrified' here. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
> SVN was _not_ broken. > > Face it. > > In fact, you could even manage files with 'case problems' under Windows, > and you could even _work_ with them if you really wanted. Not on NTFS or > FAT, of course. Hä? I couldn't check out/in anything. My SVN makes lots of troubles and after a checkout try I 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. 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 to begin personal flame wars. My intention was to lead to focus back to bug fixing than to more renaming actions. regards Uwe
Re: Stop the renamings now!!! was: More file/class name changes?
On Mon, Apr 30, 2007 at 01:06:18AM +0200, Uwe Stöhr wrote: > > SVN was _not_ broken. > > > > Face it. > > > > In fact, you could even manage files with 'case problems' under Windows, > > and you could even _work_ with them if you really wanted. Not on NTFS or > > FAT, of course. > > Hä? I couldn't check out/in anything. 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. Second, you could if you wanted to. See below. > My SVN makes lots of troubles and after a checkout try I got a totally > broken tree. [Just because TortoiseSVN bails out doesn't mean you have a broken SVN tree... Anyway...] > On Windows I have of course only FAT and NTFS, in my case only NTFS. This 'of course' is a limitation imposed by yourself. There is no problem to have e.g. ext2 partitions under Windows (and about a dozen other filesystems for that matter). I haven't actually tried, but I'd expect that you can even have ext2 within a _file_ using the Deamon tools or such, so you'd probably not even need a partition for that. > >> 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. 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 every single rename by starting with a clean tree I/we would not have been able to finish within a week. Having everything in a big commit would not have worked either as there had been several substantial changes outside that would have broken the 'single shot rename'. > 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. See above. I doubt your tree was actually broken. However, I understand you are not happy that it did not work out-of-the-box _twice_ this week. > I think we can close this discussion now as it was not my intention to > begin personal flame wars. My intention was to lead to focus back to > bug fixing than to more renaming actions. I have no problems with personal flame wars as long as the technical issues are stated correctly. Andre'
Re: Stop the renamings now!!! was: More file/class name changes?
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 after a checkout try I got a totally broken tree. [Just because TortoiseSVN bails out doesn't mean you have a broken SVN tree... Anyway...] If TortoiseSVN fails to checkout the tree is broken for me as result. On Windows I have of course only FAT and NTFS, in my case only NTFS. This 'of course' is a limitation imposed by yourself. There is no problem to have e.g. ext2 partitions under Windows... Come on, NTFS and FAT is used by all Win systems as standard so there's no discussion that we have to take care of them. 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. See above. I doubt your tree was actually broken. However, I understand you are not happy that it did not work out-of-the-box _twice_ this week. But you don't care about my problem, you just "broke" (tell it as you like) it again with "Text.cpp". I mean you know the problematic but still don't check if a renaming leads to two files with the same name. Checking this could not be that difficult. regards Uwe
List of renamings and merges? (Was:....)
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
Re: List of renamings and merges? (Was:....)
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
Re: Stop the renamings now!!! was: More file/class name changes?
>>> 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
Renamings
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 RowPainter, which is used only
locally, so it does not show up in the .h. I'd prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
Andre'
Re: Renamings
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 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 prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
Those arguments seems sensible to me. :-)
Andre'
--
José Abílio
Re: Renamings
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 prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
If you do the class renames, I will do file rename.
Bo
Re: Renamings
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 is all about a class RowPainter, which is used only
locally, so it does not show up in the .h. I'd prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
May I ask to fix src/frontends/controllers/ControlTabular.cpp also?
After moving and renaming LyxTabular the tree is broken...
Thank you.
Stephan
Re: Renamings
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 used only
locally, so it does not show up in the .h. I'd prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
If you do the class renames, I will do file rename.
I'll do class and file and leave the scons stuff to you...
Andre'
Re: Renamings
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 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 prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
May I ask to fix src/frontends/controllers/ControlTabular.cpp also?
After moving and renaming LyxTabular the tree is broken...
Thank you.
Done.
Andre'
Re: Renamings
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/ 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 prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
May I ask to fix src/frontends/controllers/ControlTabular.cpp also?
After moving and renaming LyxTabular the tree is broken...
Thank you.
Done.
Thank you.
But I had to revert your LCursor = Cursor rename to make it compile.
I'll wait a little bit to check again later...
Stephan
Renamings
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 RowPainter, which is used only
locally, so it does not show up in the .h. I'd prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
Andre'
Re: Renamings
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 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 prefer 'RowPainter'
>as file names here.
>
> 3. I'd rather rename classes kb_keymap into KeyMap, and the files
>in KeyMap.{h,cpp}.
Those arguments seems sensible to me. :-)
> Andre'
--
José Abílio
Re: Renamings
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 prefer 'RowPainter'
as file names here.
3. I'd rather rename classes kb_keymap into KeyMap, and the files
in KeyMap.{h,cpp}.
If you do the class renames, I will do file rename.
Bo
Re: Renamings
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 is all about a class RowPainter, which is used only
>locally, so it does not show up in the .h. I'd prefer 'RowPainter'
>as file names here.
>
> 3. I'd rather rename classes kb_keymap into KeyMap, and the files
>in KeyMap.{h,cpp}.
>
May I ask to fix src/frontends/controllers/ControlTabular.cpp also?
After moving and renaming LyxTabular the tree is broken...
Thank you.
Stephan
Re: Renamings
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 used only
> > locally, so it does not show up in the .h. I'd prefer 'RowPainter'
> > as file names here.
> >
> >3. I'd rather rename classes kb_keymap into KeyMap, and the files
> > in KeyMap.{h,cpp}.
>
> If you do the class renames, I will do file rename.
I'll do class and file and leave the scons stuff to you...
Andre'
Re: Renamings
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 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 prefer 'RowPainter'
> >as file names here.
> >
> > 3. I'd rather rename classes kb_keymap into KeyMap, and the files
> >in KeyMap.{h,cpp}.
> >
>
> May I ask to fix src/frontends/controllers/ControlTabular.cpp also?
> After moving and renaming LyxTabular the tree is broken...
> Thank you.
Done.
Andre'
Re: Renamings
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/ 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 prefer 'RowPainter'
>>>as file names here.
>>>
>>> 3. I'd rather rename classes kb_keymap into KeyMap, and the files
>>>in KeyMap.{h,cpp}.
>>>
>> May I ask to fix src/frontends/controllers/ControlTabular.cpp also?
>> After moving and renaming LyxTabular the tree is broken...
>> Thank you.
>
> Done.
Thank you.
But I had to "revert" your LCursor => Cursor rename to make it compile.
I'll wait a little bit to check again later...
Stephan
Re: File renamings after beta 2?
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 convention, use it. I am not sure what we are trying to achieve. JMarc
renamings (2)
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 (#include QBoxDialog.h in QBox.h, QBoxDialog is friend of QBox etc) in general, yet the files themselves are tiny (i.e. poison for build times [and navigation...]). Comments? Andre'
Re: renamings (2)
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 QFoo.[Ch] whenever it makes sense.
The dependencies are pretty strong (#include QBoxDialog.h in QBox.h,
QBoxDialog is friend of QBox etc) in general, yet the files themselves
are tiny (i.e. poison for build times [and navigation...]).
Comments?
Would look like the attached patch for the Box dialog. Saves 30+ lines
and reduces compile times for this particular pair of files to exactly
50%.
Andre'
Index: qt4/QBox.h
===
--- qt4/QBox.h (revision 17935)
+++ qt4/QBox.h (working copy)
@@ -13,16 +13,38 @@
#ifndef QBOX_H
#define QBOX_H
-#include QBoxDialog.h
#include QDialogView.h
+#include ui/BoxUi.h
+
+#include QCloseEvent
+#include QDialog
+
#include vector
+
namespace lyx {
namespace frontend {
class ControlBox;
+class QBox;
+class QBoxDialog : public QDialog, public Ui::QBoxUi {
+ Q_OBJECT
+public:
+ QBoxDialog(QBox * form);
+protected Q_SLOTS:
+ virtual void change_adaptor();
+ virtual void innerBoxChanged(const QString );
+ virtual void typeChanged(int);
+ virtual void restoreClicked();
+protected:
+ virtual void closeEvent(QCloseEvent * e);
+private:
+ QBox * form_;
+};
+
+
///
class QBox
: public QControllerControlBox, QViewQBoxDialog
Index: qt4/QBoxDialog.h
===
--- qt4/QBoxDialog.h (revision 17935)
+++ qt4/QBoxDialog.h (working copy)
@@ -1,43 +0,0 @@
-// -*- C++ -*-
-/**
- * \file QBoxDialog.h
- * This file is part of LyX, the document processor.
- * Licence details can be found in the file COPYING.
- *
- * \author Jürgen Spitzmüller
- *
- * Full author contact details are available in file CREDITS.
- */
-
-#ifndef QBOXDIALOG_H
-#define QBOXDIALOG_H
-
-#include ui/BoxUi.h
-
-#include QCloseEvent
-#include QDialog
-
-namespace lyx {
-namespace frontend {
-
-class QBox;
-
-class QBoxDialog : public QDialog, public Ui::QBoxUi {
- Q_OBJECT
-public:
- QBoxDialog(QBox * form);
-protected Q_SLOTS:
- virtual void change_adaptor();
- virtual void innerBoxChanged(const QString );
- virtual void typeChanged(int);
- virtual void restoreClicked();
-protected:
- virtual void closeEvent(QCloseEvent * e);
-private:
- QBox * form_;
-};
-
-} // namespace frontend
-} // namespace lyx
-
-#endif // QBOXDIALOG_H
Index: qt4/Makefile.dialogs
===
--- qt4/Makefile.dialogs (revision 17936)
+++ qt4/Makefile.dialogs (working copy)
@@ -89,7 +89,7 @@
QAboutDialog.C QAboutDialog.h \
QBibitemDialog.C QBibitemDialog.h \
QBibtexDialog.C QBibtexDialog.h \
- QBoxDialog.C QBoxDialog.h \
+ QBox.C QBox.h \
QBranchDialog.C QBranchDialog.h \
QBranches.C QBranches.h \
QChangesDialog.C QChangesDialog.h \
Index: qt4/QBox.C
===
--- qt4/QBox.C (revision 17935)
+++ qt4/QBox.C (working copy)
@@ -16,12 +16,11 @@
#include checkedwidgets.h
#include lengthcombo.h
-#include QBoxDialog.h
#include qt_helpers.h
#include Qt2BC.h
-
#include lengthcommon.h
#include lyxrc.h // to set the default length values
+#include validators.h
#include controllers/ControlBox.h
#include controllers/helper_funcs.h
@@ -32,17 +31,117 @@
#include QPushButton
#include QLineEdit
+#include QCloseEvent
-#include vector
using lyx::support::getStringFromVector;
using lyx::support::isStrDbl;
using lyx::support::subst;
using std::string;
+
namespace lyx {
namespace frontend {
+//
+//
+// QBoxDialog
+//
+//
+
+QBoxDialog::QBoxDialog(QBox * form)
+ : form_(form)
+{
+ setupUi(this);
+ connect(restorePB, SIGNAL(clicked()), form, SLOT(slotRestore()));
+ connect(okPB, SIGNAL(clicked()), form, SLOT(slotOK()));
+ connect(applyPB, SIGNAL(clicked()), form, SLOT(slotApply()));
+ connect(closePB, SIGNAL(clicked()), form, SLOT(slotClose()));
+
+ connect(widthED, SIGNAL(textChanged(const QString )),
+ this, SLOT(change_adaptor()));
+ connect(widthUnitsLC, SIGNAL(selectionChanged(lyx::LyXLength::UNIT)),
+ this, SLOT(change_adaptor()));
+ connect(valignCO, SIGNAL(highlighted(const QString )),
+ this, SLOT(change_adaptor()));
+ connect(heightED, SIGNAL(textChanged(const QString )),
+ this, SLOT(change_adaptor()));
+ connect(heightUnitsLC, SIGNAL(selectionChanged(lyx::LyXLength::UNIT) ),
+ this, SLOT(change_adaptor()));
+ connect(restorePB, SIGNAL(clicked()), this, SLOT(restoreClicked()));
+ connect(typeCO, SIGNAL(activated(int)), this, SLOT(change_adaptor()));
+ connect(typeCO, SIGNAL(activated(int)), this, SLOT(typeChanged(int)));
+ connect(halignCO,
Re: renamings (2)
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 are pretty strong (#include QBoxDialog.h in
QBox.h, QBoxDialog is friend of QBox etc) in general, yet the files
themselves are tiny (i.e. poison for build times [and
navigation...]).
Comments?
Did you read mine? I repeat them just in case:
Andre Poenitz wrote:
In the medium term (i.e. not today, but before 1.5.0 proper) I'd like
to merge in src/frontend the Foo.{h,C} and FooDialog.{h,C} files to a
single one.
I think you mean in src/frontend/qt4. Do you mean putting the two
classes into one file or merging the two classes?
Looking at possible name clashes, I'd prefer the 'FooDialog' version.
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 dialogs
or in a dock widget).
Both files are interdependent anyway and tiny, and with look at our
compile times this situation should be avoided.
Note though that not all of them shall be merged. For example QCitation
and QCitationDialog shall _not_ be merged. If you want to rename them,
that would be:
QCitation - CitationModel
CitationDialog - CitationWidget
CitationModel derives from ControlCitation so this is not only a model
but also a controller. But it's a good compromise as ControlCitation
is already taken. Post 1.5, we could probably re-factor that to get the
Model/Control separation.
Same goes for QToc and TocWidget. QToc can be renamed to TocModel.
Abdel.
Re: renamings (2)
On Tue, Apr 24, 2007 at 11:41:53AM +0200, Abdelrazak Younes wrote: I think you mean in src/frontend/qt4. Do you mean putting the two classes into one file or merging the two classes? Right now I mean putting two classes into one file. 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. 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 dialogs or in a dock widget). Fine with me. But this is more than I want to do now myself. Both files are interdependent anyway and tiny, and with look at our compile times this situation should be avoided. Note though that not all of them shall be merged. For example QCitation and QCitationDialog shall _not_ be merged. If you want to rename them, that would be: QCitation - CitationModel CitationDialog - CitationWidget CitationModel derives from ControlCitation so this is not only a model but also a controller. But it's a good compromise as ControlCitation is already taken. Post 1.5, we could probably re-factor that to get the Model/Control separation. Correct me if I am wrong, but 'usually' one has a model and a sort-of-combined view/controller. Not model/controler vs view. Andre'
Re: renamings (2)
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Tue, Apr 24, 2007 at 11:41:53AM +0200, Abdelrazak Younes Andre wrote: I think you mean in src/frontend/qt4. Do you mean putting the two classes into one file 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
Re: renamings (2)
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
Re: renamings (2)
Andre Poenitz wrote: On Tue, Apr 24, 2007 at 11:41:53AM +0200, Abdelrazak Younes wrote: I think you mean in src/frontend/qt4. Do you mean putting the two classes into one file or merging the two classes? Right now I mean putting two classes into one file. 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 to QWidget for all dialogs (so that it can be embedded in other dialogs or in a dock widget). Fine with me. But this is more than I want to do now myself. OK. Both files are interdependent anyway and tiny, and with look at our compile times this situation should be avoided. Note though that not all of them shall be merged. For example QCitation and QCitationDialog shall _not_ be merged. If you want to rename them, that would be: QCitation - CitationModel CitationDialog - CitationWidget CitationModel derives from ControlCitation so this is not only a model but also a controller. But it's a good compromise as ControlCitation is already taken. Post 1.5, we could probably re-factor that to get the Model/Control separation. Correct me if I am wrong, but 'usually' one has a model and a sort-of-combined view/controller. Not model/controler vs view. That's just the way it turned out to be. Actually, the view has some controls embedded in it. Abdel.
Re: File renamings after beta 2?
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
Re: File renamings after beta 2?
On Tue, Apr 24, 2007 at 09:15:33AM -0500, Bo Peng wrote: 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. Classes should be named accordingly 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'
Re: File renamings after beta 2?
> "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 convention, use it." I am not sure what we are trying to achieve. JMarc
renamings (2)
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 (#include "QBoxDialog.h" in QBox.h, QBoxDialog is friend of QBox etc) in general, yet the files themselves are tiny (i.e. poison for build times [and navigation...]). Comments? Andre'
Re: renamings (2)
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 QFoo.[Ch] whenever it makes sense.
>
> The dependencies are pretty strong (#include "QBoxDialog.h" in QBox.h,
> QBoxDialog is friend of QBox etc) in general, yet the files themselves
> are tiny (i.e. poison for build times [and navigation...]).
>
> Comments?
Would look like the attached patch for the Box dialog. Saves 30+ lines
and reduces compile times for this particular pair of files to exactly
50%.
Andre'
Index: qt4/QBox.h
===
--- qt4/QBox.h (revision 17935)
+++ qt4/QBox.h (working copy)
@@ -13,16 +13,38 @@
#ifndef QBOX_H
#define QBOX_H
-#include "QBoxDialog.h"
#include "QDialogView.h"
+#include "ui/BoxUi.h"
+
+#include
+#include
+
#include
+
namespace lyx {
namespace frontend {
class ControlBox;
+class QBox;
+class QBoxDialog : public QDialog, public Ui::QBoxUi {
+ Q_OBJECT
+public:
+ QBoxDialog(QBox * form);
+protected Q_SLOTS:
+ virtual void change_adaptor();
+ virtual void innerBoxChanged(const QString &);
+ virtual void typeChanged(int);
+ virtual void restoreClicked();
+protected:
+ virtual void closeEvent(QCloseEvent * e);
+private:
+ QBox * form_;
+};
+
+
///
class QBox
: public QController
Index: qt4/QBoxDialog.h
===
--- qt4/QBoxDialog.h (revision 17935)
+++ qt4/QBoxDialog.h (working copy)
@@ -1,43 +0,0 @@
-// -*- C++ -*-
-/**
- * \file QBoxDialog.h
- * This file is part of LyX, the document processor.
- * Licence details can be found in the file COPYING.
- *
- * \author Jürgen Spitzmüller
- *
- * Full author contact details are available in file CREDITS.
- */
-
-#ifndef QBOXDIALOG_H
-#define QBOXDIALOG_H
-
-#include "ui/BoxUi.h"
-
-#include
-#include
-
-namespace lyx {
-namespace frontend {
-
-class QBox;
-
-class QBoxDialog : public QDialog, public Ui::QBoxUi {
- Q_OBJECT
-public:
- QBoxDialog(QBox * form);
-protected Q_SLOTS:
- virtual void change_adaptor();
- virtual void innerBoxChanged(const QString &);
- virtual void typeChanged(int);
- virtual void restoreClicked();
-protected:
- virtual void closeEvent(QCloseEvent * e);
-private:
- QBox * form_;
-};
-
-} // namespace frontend
-} // namespace lyx
-
-#endif // QBOXDIALOG_H
Index: qt4/Makefile.dialogs
===
--- qt4/Makefile.dialogs (revision 17936)
+++ qt4/Makefile.dialogs (working copy)
@@ -89,7 +89,7 @@
QAboutDialog.C QAboutDialog.h \
QBibitemDialog.C QBibitemDialog.h \
QBibtexDialog.C QBibtexDialog.h \
- QBoxDialog.C QBoxDialog.h \
+ QBox.C QBox.h \
QBranchDialog.C QBranchDialog.h \
QBranches.C QBranches.h \
QChangesDialog.C QChangesDialog.h \
Index: qt4/QBox.C
===
--- qt4/QBox.C (revision 17935)
+++ qt4/QBox.C (working copy)
@@ -16,12 +16,11 @@
#include "checkedwidgets.h"
#include "lengthcombo.h"
-#include "QBoxDialog.h"
#include "qt_helpers.h"
#include "Qt2BC.h"
-
#include "lengthcommon.h"
#include "lyxrc.h" // to set the default length values
+#include "validators.h"
#include "controllers/ControlBox.h"
#include "controllers/helper_funcs.h"
@@ -32,17 +31,117 @@
#include
#include
+#include
-#include
using lyx::support::getStringFromVector;
using lyx::support::isStrDbl;
using lyx::support::subst;
using std::string;
+
namespace lyx {
namespace frontend {
+//
+//
+// QBoxDialog
+//
+//
+
+QBoxDialog::QBoxDialog(QBox * form)
+ : form_(form)
+{
+ setupUi(this);
+ connect(restorePB, SIGNAL(clicked()), form, SLOT(slotRestore()));
+ connect(okPB, SIGNAL(clicked()), form, SLOT(slotOK()));
+ connect(applyPB, SIGNAL(clicked()), form, SLOT(slotApply()));
+ connect(closePB, SIGNAL(clicked()), form, SLOT(slotClose()));
+
+ connect(widthED, SIGNAL(textChanged(const QString &)),
+ this, SLOT(change_adaptor()));
+ connect(widthUnitsLC, SIGNAL(selectionChanged(lyx::LyXLength::UNIT)),
+ this, SLOT(change_adaptor()));
+ connect(valignCO, SIGNAL(highlighted(const QString &)),
+ this, SLOT(change_adaptor()));
+ connect(heightED, SIGNAL(textChanged(const QString &)),
+ this, SLOT(change_adaptor()));
+ connect(heightUnitsLC, SIGNAL(selectionChanged(lyx::LyXLength::UNIT) ),
+ this, SLOT(change_adaptor()));
+ connect(restorePB, SIGNAL(clicked()), this, SLOT(restoreClicked()));
+ connect(typeCO, SIGNAL(activated(int)), this, SLOT(change_adaptor()));
+ connect(typeCO, SIGNAL(activated(int)), this, SLOT(typeChanged(int)));
+ connect(halignCO, SIGNAL(activated(int)), this, SLOT(change_adaptor()));
Re: renamings (2)
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 are pretty strong (#include "QBoxDialog.h" in
QBox.h, QBoxDialog is friend of QBox etc) in general, yet the files
themselves are tiny (i.e. poison for build times [and
navigation...]).
Comments?
Did you read mine? I repeat them just in case:
Andre Poenitz wrote:
In the medium term (i.e. not today, but before 1.5.0 proper) I'd like
to merge in src/frontend the Foo.{h,C} and FooDialog.{h,C} files to a
single one.
I think you mean in src/frontend/qt4. Do you mean "putting the two
classes into one file" or "merging the two classes"?
Looking at possible name clashes, I'd prefer the 'FooDialog' version.
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 dialogs
or in a dock widget).
Both files are interdependent anyway and tiny, and with look at our
compile times this situation should be avoided.
Note though that not all of them shall be merged. For example QCitation
and QCitationDialog shall _not_ be merged. If you want to rename them,
that would be:
QCitation -> CitationModel
CitationDialog -> CitationWidget
CitationModel derives from ControlCitation so this is not only a model
but also a controller. But it's a good compromise as "ControlCitation"
is already taken. Post 1.5, we could probably re-factor that to get the
Model/Control separation.
Same goes for QToc and TocWidget. QToc can be renamed to TocModel.
Abdel.
Re: renamings (2)
On Tue, Apr 24, 2007 at 11:41:53AM +0200, Abdelrazak Younes wrote: > I think you mean in src/frontend/qt4. Do you mean "putting the two > classes into one file" or "merging the two classes"? Right now I mean "putting two classes into one file". 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. > 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 dialogs > or in a dock widget). Fine with me. But this is more than I want to do now myself. > >Both files are interdependent anyway and tiny, and with look at our > >compile times this situation should be avoided. > > Note though that not all of them shall be merged. For example QCitation > and QCitationDialog shall _not_ be merged. If you want to rename them, > that would be: > > QCitation -> CitationModel > CitationDialog -> CitationWidget > > CitationModel derives from ControlCitation so this is not only a model > but also a controller. But it's a good compromise as "ControlCitation" > is already taken. Post 1.5, we could probably re-factor that to get the > Model/Control separation. Correct me if I am wrong, but 'usually' one has a model and a sort-of-combined view/controller. Not model/controler vs view. Andre'
Re: renamings (2)
>>>>> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Tue, Apr 24, 2007 at 11:41:53AM +0200, Abdelrazak Younes Andre> wrote: >> I think you mean in src/frontend/qt4. Do you mean "putting the two >> classes into one file" 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
Re: renamings (2)
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
Re: renamings (2)
Andre Poenitz wrote: On Tue, Apr 24, 2007 at 11:41:53AM +0200, Abdelrazak Younes wrote: I think you mean in src/frontend/qt4. Do you mean "putting the two classes into one file" or "merging the two classes"? Right now I mean "putting two classes into one file". 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 to QWidget for all dialogs (so that it can be embedded in other dialogs or in a dock widget). Fine with me. But this is more than I want to do now myself. OK. Both files are interdependent anyway and tiny, and with look at our compile times this situation should be avoided. Note though that not all of them shall be merged. For example QCitation and QCitationDialog shall _not_ be merged. If you want to rename them, that would be: QCitation -> CitationModel CitationDialog -> CitationWidget CitationModel derives from ControlCitation so this is not only a model but also a controller. But it's a good compromise as "ControlCitation" is already taken. Post 1.5, we could probably re-factor that to get the Model/Control separation. Correct me if I am wrong, but 'usually' one has a model and a sort-of-combined view/controller. Not model/controler vs view. That's just the way it turned out to be. Actually, the view has some controls embedded in it. Abdel.
Re: File renamings after beta 2?
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
Re: File renamings after beta 2?
On Tue, Apr 24, 2007 at 09:15:33AM -0500, Bo Peng wrote: > >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. Classes should be named accordingly > 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'
Re: File renamings after beta 2?
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 http://www.md.kth.se/~chr
Re: File renamings after beta 2?
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 prepared to dealing with X11 headers defining strange macros with names that collide with our new names. But we will probably be able to deal with that... JMarc
Re: File renamings after beta 2?
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 lines of 'ok' -- 'I don't care'. There was nobody insisting on .C as far as I rememeber. Andre'
Re: File renamings after beta 2?
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 like s/QL//g and s/Q//g in Andre src/frontends/qt4. Note that we have to be prepared to dealing with X11 headers defining strange macros with names that collide with our new names. But we will probably be able to deal with that... I am aware of that. Thanks for the reminder, though. Andre'
Re: File renamings after beta 2?
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 s/QBibtex.C/Bibtex.C/g s/QBibtex.h/Bibtex.h/g s/QBibtexDialog.C/BibtexDialog.C/g s/QBibtexDialog.h/BibtexDialog.h/g s/QBox.C/Box.C/g s/QBox.h/Box.h/g s/QBoxDialog.C/BoxDialog.C/g s/QBoxDialog.h/BoxDialog.h/g s/QBranch.C/Branch.C/g s/QBranch.h/Branch.h/g s/QBranchDialog.C/BranchDialog.C/g s/QBranchDialog.h/BranchDialog.h/g s/QBranches.C/Branches.C/g s/QBranches.h/Branches.h/g s/QChanges.C/Changes.C/g s/QChanges.h/Changes.h/g s/QChangesDialog.C/ChangesDialog.C/g s/QChangesDialog.h/ChangesDialog.h/g s/QCharacter.C/Character.C/g s/QCharacter.h/Character.h/g s/QCharacterDialog.C/CharacterDialog.C/g s/QCharacterDialog.h/CharacterDialog.h/g s/QCitation.C/Citation.C/g s/QCitation.h/Citation.h/g s/QCitationDialog.C/CitationDialog.C/g s/QCitationDialog.h/CitationDialog.h/g s/QCommandBuffer.C/CommandBuffer.C/g s/QCommandBuffer.h/CommandBuffer.h/g s/QCommandEdit.C/CommandEdit.C/g s/QCommandEdit.h/CommandEdit.h/g s/QDelimiterDialog.C/DelimiterDialog.C/g s/QDelimiterDialog.h/DelimiterDialog.h/g s/QDialogView.C/DialogView.C/g s/QDialogView.h/DialogView.h/g s/QDocument.C/Document.C/g s/QDocument.h/Document.h/g s/QDocumentDialog.C/DocumentDialog.C/g s/QDocumentDialog.h/DocumentDialog.h/g s/QERT.C/ERT.C/g s/QERT.h/ERT.h/g s/QERTDialog.C/ERTDialog.C/g s/QERTDialog.h/ERTDialog.h/g s/QErrorList.C/ErrorList.C/g s/QErrorList.h/ErrorList.h/g s/QErrorListDialog.C/ErrorListDialog.C/g s/QErrorListDialog.h/ErrorListDialog.h/g s/QExternal.C/External.C/g s/QExternal.h/External.h/g s/QExternalDialog.C/ExternalDialog.C/g s/QExternalDialog.h/ExternalDialog.h/g s/QFloat.C/Float.C/g s/QFloat.h/Float.h/g s/QFloatDialog.C/FloatDialog.C/g s/QFloatDialog.h/FloatDialog.h/g s/QGraphics.C/Graphics.C/g s/QGraphics.h/Graphics.h/g s/QGraphicsDialog.C/GraphicsDialog.C/g s/QGraphicsDialog.h/GraphicsDialog.h/g s/QGraphicsUi.h/GraphicsUi.h/g s/QInclude.C/Include.C/g s/QInclude.h/Include.h/g s/QIncludeDialog.C/IncludeDialog.C/g s/QIncludeDialog.h/IncludeDialog.h/g s/QIndex.C/Index.C/g s/QIndex.h/Index.h/g s/QIndexDialog.C/IndexDialog.C/g s/QIndexDialog.h/IndexDialog.h/g s/QLImage.C/Image.C/g s/QLImage.h/Image.h/g s/QLMenubar.C/Menubar.C/g s/QLMenubar.h/Menubar.h/g s/QLPainter.C/Painter.C/g s/QLPainter.h/Painter.h/g s/QLPopupMenu./PopupMenu.C/g s/QLPopupMenu.h/PopupMenu.h/g s/QLPrintDialog.C/PrintDialog.C/g s/QLPrintDialog.h/PrintDialog.h/g s/QLToolbar.C/Toolbar.C/g s/QLToolbar.h/Toolbar.h/g s/QLog.C/Log.C/g s/QLog.h/Log.h/g s/QLogDialog.C/LogDialog.C/g s/QLogDialog.h/LogDialog.h/g s/QLyXKeySym.C/KeySym.C/g s/QLyXKeySym.h/KeySym.h/g s/QMathMatrixDialog.C/MathMatrixDialog.C/g s/QMathMatrixDialog.h/MathMatrixDialog.h/g s/QNomencl.C/Nomencl.C/g s/QNomencl.h/Nomencl.h/g s/QNomenclDialog.C/NomenclDialog.C/g s/QNomenclDialog.h/NomenclDialog.h/g s/QNote.C/Note.C/g s/QNote.h/Note.h/g s/QNoteDialog.C/NoteDialog.C/g s/QNoteDialog.h/NoteDialog.h/g s/QParagraph.C/Paragraph.C/g s/QParagraph.h/Paragraph.h/g s/QParagraphDialog.C/ParagraphDialog.C/g s/QParagraphDialog.h/ParagraphDialog.h/g s/QPrefs.C/Prefs.C/g s/QPrefs.h/Prefs.h/g s/QPrefsDialog.C/PrefsDialog.C/g s/QPrefsDialog.h/PrefsDialog.h/g s/QPrint.C/Print.C/g s/QPrint.h/Print.h/g s/QRef.C/Ref.C/g s/QRef.h/Ref.h/g s/QRefDialog.C/RefDialog.C/g s/QRefDialog.h/RefDialog.h/g s/QSearch.C/Search.C/g s/QSearch.h/Search.h/g s/QSearchDialog.C/SearchDialog.C/g s/QSearchDialog.h/SearchDialog.h/g s/QSendto.C/Sendto.C/g s/QSendto.h/Sendto.h/g s/QSendtoDialog.C/SendtoDialog.C/g s/QSendtoDialog.h/SendtoDialog.h/g s/QShowFile.C/ShowFile.C/g s/QShowFile.h/ShowFile.h/g s/QShowFileDialog.C/ShowFileDialog.C/g s/QShowFileDialog.h/ShowFileDialog.h/g s/QSpellchecker.C/Spellchecker.C/g s/QSpellchecker.h/Spellchecker.h/g s/QSpellcheckerDialog.C/SpellcheckerDialog.C/g s/QSpellcheckerDialog.h/SpellcheckerDialog.h/g s/QTabular.C/Tabular.C/g s/QTabular.h/Tabular.h/g s/QTabularCreate.C/TabularCreate.C/g s/QTabularCreate.h/TabularCreate.h/g s/QTabularCreateDialog.C/TabularCreateDialog.C/g s/QTabularCreateDialog.h/TabularCreateDialog.h/g s/QTabularDialog.C/TabularDialog.C/g s/QTabularDialog.h/TabularDialog.h/g s/QTexinfo.C/Texinfo.C/g s/QTexinfo.h/Texinfo.h/g s/QTexinfoDialog.C/TexinfoDialog.C/g s/QTexinfoDialog.h/TexinfoDialog.h/g s/QThesaurus.C/Thesaurus.C/g s/QThesaurus.h/Thesaurus.h/g s/QThesaurusDialog.C/ThesaurusDialog.C/g s/QThesaurusDialog.h/ThesaurusDialog.h/g s/QToc.C/Toc.C/g s/QToc.h/Toc.h/g s/QURLDialog.C/URLDialog.C/g s/QURLDialog.h/URLDialog.h/g s/QVSpace.C/VSpace.C/g s/QVSpace.h/VSpace.h/g s/QVSpaceDialog.C/VSpaceDialog.C/g s/QVSpaceDialog.h/VSpaceDialog.h/g s/QViewSource.C/ViewSource.C/g s/QViewSource.h/ViewSource.h/g s/QViewSourceDialog.C/ViewSourceDialog.C/g s/QViewSourceDialog.h/ViewSourceDialog.h/g s/QWrap.C/Wrap.C/g s/QWrap.h/Wrap.h/g
Re: File renamings after beta 2?
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 was along the lines of 'ok' -- 'I don't care'. There was nobody insisting on .C as far as I rememeber. Lars was because of his XML branch IIRC. I reckon this is not a strong argument anyway because it is easy enough to change the extension in there also. IMHO of course. +1 for the Q* renaming +1 for the .C - .cpp renaming Abdel.
Re: File renamings after beta 2?
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, but then again I'm lazy as I don't go and look...) Consensus was along the lines of 'ok' -- 'I don't care'. There was nobody insisting on .C as far as I rememeber. Lars was because of his XML branch IIRC. I don't remember, but Lars might have also been opposed for some other reasion. I reckon this is not a strong argument anyway because it is easy enough to change the extension in there also. IMHO of course. +1 for the Q* renaming +1 for the .C - .cpp renaming 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] /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: File renamings after beta 2?
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 that, but then again I'm lazy as I don't go and look...) Consensus was along the lines of 'ok' -- 'I don't care'. There was nobody insisting on .C as far as I rememeber. I remember being opposed. .cpp, .hpp is a windowsism. - Martin
Re: File renamings after beta 2?
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
Re: File renamings after beta 2?
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'
Re: File renamings after beta 2?
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 overcame with some efforts). When I used this as an argument, Lars, IIRC, refused to do anything 'just for windoze', which sounds a bit condescending. Bo
Re: File renamings after beta 2?
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 You guys decide. Bo
Re: File renamings after beta 2?
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 lyx_find lyx_glue_length lyx_textclasslist cursor_slice You guys decide. The first version. Abdel.
Re: File renamings after beta 2?
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
Re: File renamings after beta 2?
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 general feeling for this, then by all means go ahead and make the world an ever-so-slightly uglier place. I'll get used to it ;-/ - Martin
Re: File renamings after beta 2?
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 are the same under windows, and caused some trouble in scons (which I overcame with some efforts). When I used this as an argument, Lars, IIRC, refused to do anything 'just for windoze', which sounds a bit condescending. Bo Let the few suffer for the many :-) Seriously, condescending about sums it up. Sure, we should support all platforms out there -- and I appreciate yours and others' willingness to suffer for the good cause --, but let's keep our development process a *nix one, as the good Lord intended ;-) Anyway, seems I am outnumbered on this one. - Martin
