Re: Too much options in LyX

On 20/05/2011 8:43 AM, venom00 wrote: If this are all changes, I wouldn't touch it any more, maybe we update it later, and if we have changed it there would be too much noise in the diff. You mean update from the original Qt Creator source? Yeah, that's a good idea. Then here's the patch with

Re: Too much options in LyX

On 20/05/2011 8:43 AM, venom00 wrote: If this are all changes, I wouldn't touch it any more, maybe we update it later, and if we have changed it there would be too much noise in the diff. You mean update from the original Qt Creator source? Yeah, that's a good idea. Then here's the patch with

RE: Too much options in LyX

If this are all changes, I wouldn't touch it any more, maybe we update it later, and if we have changed it there would be too much noise in the diff. You mean update from the original Qt Creator source? Yeah, that's a good idea. Then here's the patch with camel-cased filenames. venom00

RE: Too much options in LyX

> If this are all changes, I wouldn't touch it any more, maybe > we update it later, > and if we have changed it there would be too much noise in the diff. You mean update from the original Qt Creator source? Yeah, that's a good idea. Then here's the patch with camel-cased filenames. venom00

Re: Too much options in LyX

On 18.05.2011 23:03, venom00 wrote: Are the fancylineedit.* files 1:1 copied from qtcreator? Then we should not touch them otherwise we could lyxify them. I've changed the namespace, removed an export macro and changed the copyright notice as you can see in the patch or in a previous mail. We

Re: Too much options in LyX

On 18.05.2011 23:03, venom00 wrote: Are the fancylineedit.* files 1:1 copied from qtcreator? Then we should not touch them otherwise we could lyxify them. I've changed the namespace, removed an export macro and changed the copyright notice as you can see in the patch or in a previous mail. We

RE: Too much options in LyX

And... Scons? :P However I'll test it under Linux with autotools to be sure everything is right. OK, here's the version of the patch working under Linux with autotools. So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I have to: - include the moc file at the end;

Re: Too much options in LyX

On 18.05.2011 11:51, venom00 wrote: And... Scons? :P However I'll test it under Linux with autotools to be sure everything is right. OK, here's the version of the patch working under Linux with autotools. So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I have to:

Re: Too much options in LyX

On 18.05.2011 11:51, venom00 wrote: And... Scons? :P However I'll test it under Linux with autotools to be sure everything is right. OK, here's the version of the patch working under Linux with autotools. So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I have to:

RE: Too much options in LyX

Are the fancylineedit.* files 1:1 copied from qtcreator? Then we should not touch them otherwise we could lyxify them. I've changed the namespace, removed an export macro and changed the copyright notice as you can see in the patch or in a previous mail. We should LyXify them... Whatever it

RE: Too much options in LyX

> And... Scons? :P However I'll test it under Linux with > autotools to be sure everything is right. OK, here's the version of the patch working under Linux with autotools. So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I have to: - include the moc file at the

Re: Too much options in LyX

On 18.05.2011 11:51, venom00 wrote: And... Scons? :P However I'll test it under Linux with autotools to be sure everything is right. OK, here's the version of the patch working under Linux with autotools. So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I have to:

Re: Too much options in LyX

On 18.05.2011 11:51, venom00 wrote: And... Scons? :P However I'll test it under Linux with autotools to be sure everything is right. OK, here's the version of the patch working under Linux with autotools. So if I'm correct, to add a file which needs the moc file in src/frontends/qt4 I have to:

RE: Too much options in LyX

> Are the fancylineedit.* files 1:1 copied from qtcreator? Then > we should not > touch them otherwise we could lyxify them. I've changed the namespace, removed an export macro and changed the copyright notice as you can see in the patch or in a previous mail. We should LyXify them... Whatever

Re: Too much options in LyX

On 16.05.2011 23:54, venom00 wrote: Vincent or someone else, can you tell me if it's OK to include a pair of files directly from the Qt Creator code? Just a quick reply so I can go on with the patch. Isn't QtCreator LGPL? Then it would be ok. Peter

Re: Too much options in LyX

On Mon, May 16, 2011 at 11:54 PM, venom00 veno...@arcadiaclub.com wrote: Vincent or someone else, can you tell me if it's OK to include a pair of files directly from the Qt Creator code? Just a quick reply so I can go on with the patch. Hi Venom, Sorry for not responding earlier. It feels

RE: Too much options in LyX

Hi Venom, Sorry for not responding earlier. It feels like it's a bit too much to include a pair of files from another project just to add a rubber button to your search box. Can you point at the code that you want to use. Maybe there is a simpler solution ? Vincent Maybe we can reuse it

Re: Too much options in LyX

On 17-5-2011 20:15, venom00 wrote: Hi Venom, Sorry for not responding earlier. It feels like it's a bit too much to include a pair of files from another project just to add a rubber button to your search box. Can you point at the code that you want to use. Maybe there is a simpler solution

RE: Too much options in LyX

But... I think there are quite some places where we can pimp LyX a bit and maybe we can use it in more places as you say. Very well! Is there a reason for which the moc_ file is included at the end? I've spent an hour (in cmake's lyx_automoc friends) to understand why the moc_ file

Re: Too much options in LyX

On 17-5-2011 21:37, venom00 wrote: But... I think there are quite some places where we can pimp LyX a bit and maybe we can use it in more places as you say. Very well! Is there a reason for which the moc_ file is included at the end? I've spent an hour (in cmake's lyx_automoc friends)

Re: Too much options in LyX

Is there a reason for which the moc_ file is included at the end? I've spent an The include triggers the moc generation. I've moved fancylineedit.* into qt4 (no gui code in support, only QtCore classes), then called cmake again and it build without errors. hour (in cmake's lyx_automoc

Re: Too much options in LyX

On 17.05.2011 21:46, Vincent van Ravesteijn wrote: Mmmh, now I'm starting to get confused about your question. Are you asking why you have to include the moc_* files or why the moc_* file was not created for fancylineedit ? The creation of the moc_* file is not trigged by including it.

Re: Too much options in LyX

On 17-5-2011 22:02, Peter Kümmel wrote: On 17.05.2011 21:46, Vincent van Ravesteijn wrote: Mmmh, now I'm starting to get confused about your question. Are you asking why you have to include the moc_* files or why the moc_* file was not created for fancylineedit ? The creation of the moc_*

RE: Too much options in LyX

The creation of the moc_* file is not trigged by including it. Mmmh, it seems that including it triggers its creation, take a look at the lyx_automoc macro. For how I've understood it, it checks all the file against the following regexp: #include +[]moc_[^]+\\.cpp[] And then runs the moc

Re: Too much options in LyX

On Tue, May 17, 2011 at 08:11:29AM +0200, Peter Kümmel wrote: On 16.05.2011 23:54, venom00 wrote: Vincent or someone else, can you tell me if it's OK to include a pair of files directly from the Qt Creator code? Just a quick reply so I can go on with the patch. Isn't QtCreator LGPL? Then

Re: Too much options in LyX

Am Dienstag, 17. Mai 2011 schrieb Vincent van Ravesteijn: On 17-5-2011 22:02, Peter Kümmel wrote: On 17.05.2011 21:46, Vincent van Ravesteijn wrote: Mmmh, now I'm starting to get confused about your question. Are you asking why you have to include the moc_* files or why the moc_* file was

Re: Too much options in LyX

On 16.05.2011 23:54, venom00 wrote: Vincent or someone else, can you tell me if it's OK to include a pair of files directly from the Qt Creator code? Just a quick reply so I can go on with the patch. Isn't QtCreator LGPL? Then it would be ok. Peter

Re: Too much options in LyX

On Mon, May 16, 2011 at 11:54 PM, venom00 wrote: > Vincent or someone else, can you tell me if it's OK to include a pair of > files > directly from the Qt Creator code? > Just a quick reply so I can go on with the patch. > Hi Venom, Sorry for not responding earlier.

RE: Too much options in LyX

> Hi Venom, > Sorry for not responding earlier. > It feels like it's a bit too much to include a pair of files from another project just to add a "rubber button" to your search box. > Can you point at the code that you want to use. Maybe there is a simpler solution ? > > Vincent Maybe we can

Re: Too much options in LyX

On 17-5-2011 20:15, venom00 wrote: >> Hi Venom, >> Sorry for not responding earlier. >> It feels like it's a bit too much to include a pair of files from another > project just to add a "rubber button" to your search box. >> Can you point at the code that you want to use. Maybe there is a simpler

RE: Too much options in LyX

> But... I think there are quite some places where we can pimp LyX a > bit and maybe we can use it in more places as you say. Very well! > > Is there a reason for which the moc_ file is included at > the end? I've spent an > > hour (in cmake's lyx_automoc & friends) to understand why > the

Re: Too much options in LyX

On 17-5-2011 21:37, venom00 wrote: >> But... I think there are quite some places where we can pimp LyX a >> bit and maybe we can use it in more places as you say. > > Very well! > >>> Is there a reason for which the moc_ file is included at >> the end? I've spent an >>> hour (in cmake's

Re: Too much options in LyX

Is there a reason for which the moc_ file is included at the end? I've spent an The include triggers the moc generation. I've moved fancylineedit.* into qt4 (no gui code in support, only QtCore classes), then called cmake again and it build without errors. hour (in cmake's lyx_automoc&

Re: Too much options in LyX

On 17.05.2011 21:46, Vincent van Ravesteijn wrote: Mmmh, now I'm starting to get confused about your question. Are you asking why you have to include the moc_* files or why the moc_* file was not created for fancylineedit ? The creation of the moc_* file is not trigged by including it.

Re: Too much options in LyX

On 17-5-2011 22:02, Peter Kümmel wrote: > On 17.05.2011 21:46, Vincent van Ravesteijn wrote: >> >> Mmmh, now I'm starting to get confused about your question. Are >> you asking why you have to include the moc_* files or why the >> moc_* file was not created for fancylineedit ? The creation of >>

RE: Too much options in LyX

> The creation of the moc_* file is not trigged by including it. Mmmh, it seems that including it triggers its creation, take a look at the lyx_automoc macro. For how I've understood it, it checks all the file against the following regexp: #include +["<]moc_[^]+\\.cpp[">] And then runs the moc

Re: Too much options in LyX

On Tue, May 17, 2011 at 08:11:29AM +0200, Peter Kümmel wrote: > On 16.05.2011 23:54, venom00 wrote: > >Vincent or someone else, can you tell me if it's OK to include a pair > >of files directly from the Qt Creator code? Just a quick reply so I > >can go on with the patch. > > Isn't QtCreator

Re: Too much options in LyX

Am Dienstag, 17. Mai 2011 schrieb Vincent van Ravesteijn: > On 17-5-2011 22:02, Peter Kümmel wrote: > > On 17.05.2011 21:46, Vincent van Ravesteijn wrote: > >> Mmmh, now I'm starting to get confused about your question. Are > >> you asking why you have to include the moc_* files or why the > >>

RE: Too much options in LyX

Vincent or someone else, can you tell me if it's OK to include a pair of files directly from the Qt Creator code? Just a quick reply so I can go on with the patch. Thanks, venom00 Ping The patch looks pretty good now, so I'll put it in my testing tree. I'm not completely sure of

Re: Too much options in LyX

On 05/16/2011 05:54 PM, venom00 wrote: Vincent or someone else, can you tell me if it's OK to include a pair of files directly from the Qt Creator code? Just a quick reply so I can go on with the patch. We've done this sort of thing before. Depending upon what they are, they should perhaps go

RE: Too much options in LyX

Vincent or someone else, can you tell me if it's OK to include a pair of files directly from the Qt Creator code? Just a quick reply so I can go on with the patch. Thanks, venom00 > Ping > > > > > The patch looks pretty good now, so I'll put it in my > > testing tree. > > > > > > I'm not

Re: Too much options in LyX

On 05/16/2011 05:54 PM, venom00 wrote: > Vincent or someone else, can you tell me if it's OK to include a pair of files > directly from the Qt Creator code? > Just a quick reply so I can go on with the patch. > We've done this sort of thing before. Depending upon what they are, they should perhaps

RE: Too much options in LyX

Ping The patch looks pretty good now, so I'll put it in my testing tree. I'm not completely sure of the red highlighting. Red is a color for errors, I'll try green, yellow and maybe bold. Moreover I want to add the rubber button. I was thinking to use the FancyLineEdit widget of

RE: Too much options in LyX

Ping > > > The patch looks pretty good now, so I'll put it in my > testing tree. > > > > I'm not completely sure of the red highlighting. Red is a > > color for errors, I'll try green, yellow and maybe bold. > > Moreover I want to add the "rubber" button. > > I was thinking to use the

RE: Too much options in LyX

The patch looks pretty good now, so I'll put it in my testing tree. I'm not completely sure of the red highlighting. Red is a color for errors, I'll try green, yellow and maybe bold. Moreover I want to add the rubber button. I was thinking to use the FancyLineEdit widget of Qt Creator [1]

RE: Too much options in LyX

> > The patch looks pretty good now, so I'll put it in my testing tree. > > I'm not completely sure of the red highlighting. Red is a > color for errors, I'll try green, yellow and maybe bold. > Moreover I want to add the "rubber" button. I was thinking to use the FancyLineEdit widget of Qt

RE: 80 chars rule (was: Too much options in LyX)

Vincent, why didn't you fix the thing silently? Because if I did, I would need to correct all your future patches/commits. This discussion will set a rule that (whatever it will be!) will make me crazy! Discussion or not the rule will be there. I was just joking. This

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 4, 2011 at 12:08 AM, Pavel Sanda sa...@lyx.org wrote: Andre Poenitz wrote: Anyway, 100 is probably fine, I lost that kind of battle already in other places ;-| anyone around strongly against 100-char wide rule? No. 70 to 80 is what I've seen often recommended for a text to be

Re: 80 chars rule (was: Too much options in LyX)

Vincent van Ravesteijn wrote: anyone around strongly against 100-char wide rule? YES, me ! hmm, i should also count caps lock and exclamation marks when doing next emoticons statistics... :) Normal Code please, so don't come up with 20 connects beneath each other or the like. i admit

Re: 80 chars rule (was: Too much options in LyX)

Vincent van Ravesteijn wrote: Show me an example where it would be necessary and where the 80 char limit is a pita ? another example which just jumped at me. its not strictly pita but i find the two lines better. you don't? pavel diff --git a/src/frontends/qt4/GuiToolbar.cpp

Re: 80 chars rule (was: Too much options in LyX)

On 04/05/2011 19:38, Pavel Sanda wrote: Vincent van Ravesteijn wrote: Show me an example where it would be necessary and where the 80 char limit is a pita ? another example which just jumped at me. its not strictly pita but i find the two lines better. you don't? Part of the two exceptions:

Re: 80 chars rule (was: Too much options in LyX)

Abdelrazak Younes wrote: On 04/05/2011 19:38, Pavel Sanda wrote: Vincent van Ravesteijn wrote: Show me an example where it would be necessary and where the 80 char limit is a pita ? another example which just jumped at me. its not strictly pita but i find the two lines better. you don't?

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 04, 2011 at 12:43:05PM +0200, Pavel Sanda wrote: Vincent van Ravesteijn wrote: anyone around strongly against 100-char wide rule? YES, me ! hmm, i should also count caps lock and exclamation marks when doing next emoticons statistics... :) Normal Code please, so don't

Re: 80 chars rule (was: Too much options in LyX)

that said if you agree on those few exception from 80 rule then i'll be satisfied with such outcome of our flame. Exempting certain constructs from the rule seems to be more platable then to drop the rule completely... In the case of the LYXERR0 exception: I don't care about these

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 4, 2011 at 7:38 PM, Pavel Sanda sa...@lyx.org wrote: Vincent van Ravesteijn wrote: Show me an example where it would be necessary and where the 80 char limit is a pita ? another example which just jumped at me. its not strictly pita but i find the two lines better. you don't?

Re: 80 chars rule (was: Too much options in LyX)

Vincent van Ravesteijn wrote: another example which just jumped at me. its not strictly pita but i find the two lines better. you don't? Which do you like better ? string const name = fromqstr(objectName()); visibility = guiApp-toolbars().defaultVisibility(name); or visibility =

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 4, 2011 at 10:57 PM, Pavel Sanda sa...@lyx.org wrote: Vincent van Ravesteijn wrote: another example which just jumped at me. its not strictly pita but i find the two lines better. you don't? Which do you like better ? string const name = fromqstr(objectName());

RE: 80 chars rule (was: Too much options in LyX)

Vincent, why didn't you fix the thing silently? Because if I did, I would need to correct all your future patches/commits. This discussion will set a rule that (whatever it will be!) will make me crazy! Discussion or not the rule will be there. I was just joking. This

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 4, 2011 at 12:08 AM, Pavel Sanda wrote: > Andre Poenitz wrote: >> Anyway, 100 is probably fine, I lost that kind of battle already in >> other places ;-| > > anyone around strongly against 100-char wide rule? > No. 70 to 80 is what I've seen often recommended for a text

Re: 80 chars rule (was: Too much options in LyX)

Vincent van Ravesteijn wrote: > > anyone around strongly against 100-char wide rule? > > YES, me ! hmm, i should also count caps lock and exclamation marks when doing next emoticons statistics... :) > "Normal Code" please, so don't come up with 20 connects beneath each other > or the like. i

Re: 80 chars rule (was: Too much options in LyX)

Vincent van Ravesteijn wrote: > Show me an example where it would be necessary and where the 80 char limit > is a pita ? another example which just jumped at me. its not strictly pita but i find the two lines better. you don't? pavel diff --git a/src/frontends/qt4/GuiToolbar.cpp

Re: 80 chars rule (was: Too much options in LyX)

On 04/05/2011 19:38, Pavel Sanda wrote: Vincent van Ravesteijn wrote: Show me an example where it would be necessary and where the 80 char limit is a pita ? another example which just jumped at me. its not strictly pita but i find the two lines better. you don't? Part of the two exceptions:

Re: 80 chars rule (was: Too much options in LyX)

Abdelrazak Younes wrote: > On 04/05/2011 19:38, Pavel Sanda wrote: >> Vincent van Ravesteijn wrote: >>> Show me an example where it would be necessary and where the 80 char >>> limit >>> is a pita ? >> another example which just jumped at me. its not strictly pita >> but i find the two lines

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 04, 2011 at 12:43:05PM +0200, Pavel Sanda wrote: > Vincent van Ravesteijn wrote: > > > anyone around strongly against 100-char wide rule? > > > > YES, me ! > > hmm, i should also count caps lock and exclamation marks when doing > next emoticons statistics... :) > > > "Normal Code"

Re: 80 chars rule (was: Too much options in LyX)

> > > > that said if you agree on those few exception from 80 rule then i'll be > > satisfied with such outcome of our flame. > > Exempting certain constructs from the rule seems to be more platable > then to drop the rule completely... > > In the case of the LYXERR0 exception: I don't care about

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 4, 2011 at 7:38 PM, Pavel Sanda wrote: > Vincent van Ravesteijn wrote: > > Show me an example where it would be necessary and where the 80 char > limit > > is a pita ? > > another example which just jumped at me. its not strictly pita > but i find the two lines better.

Re: 80 chars rule (was: Too much options in LyX)

Vincent van Ravesteijn wrote: > > another example which just jumped at me. its not strictly pita > > but i find the two lines better. you don't? > > > Which do you like better ? > > string const name = fromqstr(objectName()); > visibility = guiApp->toolbars().defaultVisibility(name); > > or >

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 4, 2011 at 10:57 PM, Pavel Sanda wrote: > Vincent van Ravesteijn wrote: > > > another example which just jumped at me. its not strictly pita > > > but i find the two lines better. you don't? > > > > > > Which do you like better ? > > > > string const name =

RE: Too much options in LyX

The patch looks pretty good now, so I'll put it in my testing tree. I'm not completely sure of the red highlighting. Red is a color for errors, I'll try green, yellow and maybe bold. Moreover I want to add the rubber button. Just a last nitpick: we try to keep the lines shorter than 80

80 chars rule (was: Too much options in LyX)

venom00 wrote: The patch looks pretty good now, so I'll put it in my testing tree. I'm not completely sure of the red highlighting. Red is a color for errors, I'll try green, yellow and maybe bold. Moreover I want to add the rubber button. Just a last nitpick: we try to keep the

Re: 80 chars rule (was: Too much options in LyX)

On Tuesday 03 May 2011 18:23:50 Pavel Sanda wrote: btw is it still worth to keep this rule as the displays are wider and wider? what was the rationale behind? pavel But our brains are not. ;-) There are several reasons associated, we should avoid to nest too much our code, if we have a 5

Re: 80 chars rule (was: Too much options in LyX)

On 03/05/2011 19:36, José Matos wrote: On Tuesday 03 May 2011 18:23:50 Pavel Sanda wrote: btw is it still worth to keep this rule as the displays are wider and wider? what was the rationale behind? pavel But our brains are not. ;-) There are several reasons associated, we should avoid to

Re: 80 chars rule (was: Too much options in LyX)

On Tue, May 03, 2011 at 07:23:50PM +0200, Pavel Sanda wrote: venom00 wrote: The patch looks pretty good now, so I'll put it in my testing tree. I'm not completely sure of the red highlighting. Red is a color for errors, I'll try green, yellow and maybe bold. Moreover I want to add

Re: 80 chars rule (was: Too much options in LyX)

Andre Poenitz wrote: btw is it still worth to keep this rule as the displays are wider and wider? what was the rationale behind? To enable working on the code without line wrapping. otoh it allows one logical step on one line and function has 10 instead of 20 lines... And I think it

Re: 80 chars rule (was: Too much options in LyX)

José Matos wrote: There are several reasons associated, we should avoid to nest too much our code, if we have a 5 nested levels it becomes increasingly difficult to read the code. i didnt want to use 5 nested levels. With widespread pages it is difficult to read any text, be it code or

Re: 80 chars rule (was: Too much options in LyX)

On 03/05/2011 20:43, Pavel Sanda wrote: José Matos wrote: There are several reasons associated, we should avoid to nest too much our code, if we have a 5 nested levels it becomes increasingly difficult to read the code. i didnt want to use 5 nested levels. With widespread pages it is

Re: 80 chars rule (was: Too much options in LyX)

On Tuesday 03 May 2011 19:43:07 Pavel Sanda wrote: well i dont read the code as a text. for example the second case looks much more usefull for me, since its 2x smaller in vertical sense and my eyes go through the code faster. Since you asked... honestly it seems unreadable in both cases. :-)

Re: 80 chars rule (was: Too much options in LyX)

José Matos wrote: On Tuesday 03 May 2011 19:43:07 Pavel Sanda wrote: well i dont read the code as a text. for example the second case looks much more usefull for me, since its 2x smaller in vertical sense and my eyes go through the code faster. Since you asked... honestly it seems

Re: 80 chars rule (was: Too much options in LyX)

Abdelrazak Younes wrote: I don't care so much about the 80 chars limit but certainly we should set on some limit and try to follow for the reasons above. 100? :) No. But Qt's connect can be considered as an exception IMO. and what about the lyxerr oneliners (which were the real trigger

Re: 80 chars rule (was: Too much options in LyX)

On Tuesday 03 May 2011 19:49:59 Pavel Sanda wrote: nice way how to avoid answer :) pavel If it were me I would do it like this: connect(table,SIGNAL(rowsChanged(int)), rowsSB, SLOT(setValue(int))); connect(table,SIGNAL(colsChanged(int)), columnsSB,

Re: 80 chars rule (was: Too much options in LyX)

On Tue, May 03, 2011 at 08:43:07PM +0200, Pavel Sanda wrote: José Matos wrote: There are several reasons associated, we should avoid to nest too much our code, if we have a 5 nested levels it becomes increasingly difficult to read the code. i didnt want to use 5 nested levels.

Re: 80 chars rule (was: Too much options in LyX)

On 03.05.2011 20:18, Andre Poenitz wrote: And I think it still makes a lot of sense, as people are known to place several editor side by side to use the full width of their new screens... Those people have two screens ;) Peter

RE: 80 chars rule (was: Too much options in LyX)

If it were me I would do it like this: connect(table,SIGNAL(rowsChanged(int)), rowsSB, SLOT(setValue(int))); connect(table,SIGNAL(colsChanged(int)), columnsSB, SLOT(setValue(int))); connect(rowsSB, SIGNAL(valueChanged(int)),table,

Re: 80 chars rule (was: Too much options in LyX)

On Tue, May 03, 2011 at 09:43:40PM +0200, venom00 wrote: We need a limit, 100 is perfect IMSO [1]. venom00 (is sure someone here is still developing on terminal) Terminal or not (which I do use around 50% of the time) is not the full picture, as one can have split editors in some IDEs, too

RE: 80 chars rule (was: Too much options in LyX)

Terminal or not (which I do use around 50% of the time) is not the full picture, as one can have split editors in some IDEs, too (and that's perhaps 20% of the remaining 50% for me...) That's true, otherwise I'd have suggested more than 100 chars. [1] In My Selfish Opinion, that is, given

Re: 80 chars rule (was: Too much options in LyX)

venom00 wrote: My opinion is: who is still developing on a terminal? :P that would be me. p

Re: 80 chars rule (was: Too much options in LyX)

Andre Poenitz wrote: Anyway, 100 is probably fine, I lost that kind of battle already in other places ;-| anyone around strongly against 100-char wide rule? pavel

Re: 80 chars rule (was: Too much options in LyX)

Vincent, why didn't you fix the thing silently? Because if I did, I would need to correct all your future patches/commits. This discussion will set a rule that (whatever it will be!) will make me crazy! Discussion or not the rule will be there. There is no way you will be able to

Re: 80 chars rule (was: Too much options in LyX)

On Wed, May 4, 2011 at 12:08 AM, Pavel Sanda sa...@lyx.org wrote: Andre Poenitz wrote: Anyway, 100 is probably fine, I lost that kind of battle already in other places ;-| anyone around strongly against 100-char wide rule? pavel YES, me ! Show me an example where it would be necessary

RE: Too much options in LyX

> The patch looks pretty good now, so I'll put it in my testing tree. I'm not completely sure of the red highlighting. Red is a color for errors, I'll try green, yellow and maybe bold. Moreover I want to add the "rubber" button. > Just a last nitpick: we try to keep the lines shorter than 80 >

80 chars rule (was: Too much options in LyX)

venom00 wrote: > > The patch looks pretty good now, so I'll put it in my testing tree. > > I'm not completely sure of the red highlighting. Red is a color for errors, > I'll > try green, yellow and maybe bold. > Moreover I want to add the "rubber" button. > > > Just a last nitpick: we try to

Re: 80 chars rule (was: Too much options in LyX)

On Tuesday 03 May 2011 18:23:50 Pavel Sanda wrote: > btw is it still worth to keep this rule as the displays are wider and > wider? what was the rationale behind? > > pavel But our brains are not. ;-) There are several reasons associated, we should avoid to nest too much our code, if we have a

Re: 80 chars rule (was: Too much options in LyX)

On 03/05/2011 19:36, José Matos wrote: On Tuesday 03 May 2011 18:23:50 Pavel Sanda wrote: btw is it still worth to keep this rule as the displays are wider and wider? what was the rationale behind? pavel But our brains are not. ;-) There are several reasons associated, we should avoid to

Re: 80 chars rule (was: Too much options in LyX)

On Tue, May 03, 2011 at 07:23:50PM +0200, Pavel Sanda wrote: > venom00 wrote: > > > The patch looks pretty good now, so I'll put it in my testing tree. > > > > I'm not completely sure of the red highlighting. Red is a color for errors, > > I'll > > try green, yellow and maybe bold. > > Moreover

Re: 80 chars rule (was: Too much options in LyX)

Andre Poenitz wrote: > > btw is it still worth to keep this rule as the displays are wider and wider? > > what was the rationale behind? > > To enable working on the code without line wrapping. otoh it allows one logical step on one line and function has 10 instead of 20 lines... > And I think

Re: 80 chars rule (was: Too much options in LyX)

José Matos wrote: > There are several reasons associated, we should avoid to nest too much our > code, if we have a 5 nested levels it becomes increasingly difficult to read > the code. i didnt want to use 5 nested levels. > With widespread pages it is difficult to read any text, be it code or

Re: 80 chars rule (was: Too much options in LyX)

On 03/05/2011 20:43, Pavel Sanda wrote: José Matos wrote: There are several reasons associated, we should avoid to nest too much our code, if we have a 5 nested levels it becomes increasingly difficult to read the code. i didnt want to use 5 nested levels. With widespread pages it is

Re: 80 chars rule (was: Too much options in LyX)

On Tuesday 03 May 2011 19:43:07 Pavel Sanda wrote: > well i dont read the code as a text. for example the second case > looks much more usefull for me, since its 2x smaller in vertical > sense and my eyes go through the code faster. Since you asked... honestly it seems unreadable in both cases.

Re: 80 chars rule (was: Too much options in LyX)

José Matos wrote: > On Tuesday 03 May 2011 19:43:07 Pavel Sanda wrote: > > well i dont read the code as a text. for example the second case > > looks much more usefull for me, since its 2x smaller in vertical > > sense and my eyes go through the code faster. > > Since you asked... > honestly it

Re: 80 chars rule (was: Too much options in LyX)

Abdelrazak Younes wrote: >>> I don't care so much about the 80 chars limit but certainly we should set >>> on >>> some limit and try to follow for the reasons above. >> 100? :) > > No. But Qt's connect can be considered as an exception IMO. and what about the lyxerr oneliners (which were the

  1   2   >