Re: [Development] Qt Coding Guidelines

2016-03-20 Thread Hausmann Simon
: [Development] Qt Coding Guidelines On 16 March 2016 at 21:43, Knoll Lars <lars.kn...@theqtcompany.com<mailto:lars.kn...@theqtcompany.com>> wrote: Good initiative. I think this is the right idea. Let's put the coding guidelines into .qdoc files after having a decision on the ML. We sho

Re: [Development] Qt Coding Guidelines

2016-03-20 Thread Marc Mutz
On Friday 18 March 2016 15:37:40 André Somers wrote: > Op 18/03/2016 om 09:24 schreef Rutledge Shawn: > > Forcing it on everyone that way will be controversial, because there > > is still some leeway in formatting, whereas automation would remove > > any chance of personal preference, and probably

Re: [Development] Qt Coding Guidelines

2016-03-20 Thread Welbourne Edward
Thiago Macieira said: > We have a qdoc generator. We don't have a markdown generator. > > More importantly, we know how to write qdoc syntax. There is also an "eat our own dog-food" argument somewhere here: we ask developers to document their code in qdoc, so we should be happy to use it

Re: [Development] Qt Coding Guidelines

2016-03-20 Thread Sorvig Morten
> On 16 Mar 2016, at 22:43, Knoll Lars wrote: > > We should actually consider having a section about contributing to Qt in our > documentation. Coding guidelines would fit nicely into that. But I think the > .qdoc files should rather live in qtdoc instead of

Re: [Development] Qt Coding Guidelines

2016-03-20 Thread Sergio Martins
On Friday, March 18, 2016 10:46:41 AM Koehne Kai wrote: > > -Original Message- > > From: Development [mailto:development- > > [...] > > It remains that this document is expected to be quite stable, so there > > would be some sense to having a stable URL to which we routinely copy the > >

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Samuel Gaist
On 16 mars 2016, at 16:14, Koehne Kai wrote: > Hi there, > > We have had quite some discussions about the use of C++11 features and right > API in the past on this mailing list - but if there has been a consensus > (which is sometimes hard to find out), it was

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread André Somers
Op 18/03/2016 om 18:54 schreef Allan Sandfeld Jensen: On Friday 18 March 2016, André Somers wrote: Op 18/03/2016 om 09:24 schreef Rutledge Shawn: Forcing it on everyone that way will be controversial, because there is still some leeway in formatting, whereas automation would remove any

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread André Somers
Op 18/03/2016 om 09:24 schreef Rutledge Shawn: Forcing it on everyone that way will be controversial, because there is still some leeway in formatting, whereas automation would remove any chance of personal preference, and probably screw up in some cases. But we could at least start by

[Development] Qt Coding Guidelines

2016-03-19 Thread Koehne Kai
Hi there, We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing thread. IMO it would be good to make decisions

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread André Somers
Op 16/03/2016 om 16:14 schreef Koehne Kai: Hi there, We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Knoll Lars
On 18/03/16 16:44, "Development on behalf of Thiago Macieira" wrote: >On sexta-feira, 18 de março de 2016 10:46:41 PDT Koehne Kai wrote: >> > It remains that this document is expected to be

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Koehne Kai
> -Original Message- > From: sergio On Behalf Of Sergio Martins > Sent: Thursday, March 17, 2016 3:16 PM > To: Koehne Kai <kai.koe...@theqtcompany.com> > Cc: development@qt-project.org > Subject: Re: [Development] Qt Coding Guidelines > > On Thursday, Mar

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Allan Sandfeld Jensen
On Friday 18 March 2016, André Somers wrote: > Op 18/03/2016 om 09:24 schreef Rutledge Shawn: > > Forcing it on everyone that way will be controversial, because there > > is still some leeway in formatting, whereas automation would remove > > any chance of personal preference, and probably screw

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Ziller Eike
> On Mar 16, 2016, at 20:33, André Somers wrote: > > > > Op 16/03/2016 om 16:14 schreef Koehne Kai: >> Hi there, >> >> We have had quite some discussions about the use of C++11 features and right >> API in the past on this mailing list - but if there has been a

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Stottlemyer, Brett (B.S.)
On 3/17/16, 6:24 AM, "Development on behalf of Mathias Hasselmann" wrote: > >Actually having the Qt code style as public document proved to be >extremely useful in the past to quickly shutdown this

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Jędrzej Nowacki
On Thursday 17 of March 2016 12:29:46 André Somers wrote: > Op 17/03/2016 om 11:24 schreef Mathias Hasselmann: > > Am 17.03.2016 um 10:01 schrieb Sorvig Morten: > >> How about treating the coding guidelines as \internal documentation? > >> We could then at some point build and publish it together

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Knoll Lars
I’m all for an automated solution for code formatting, so we can remove discussions/comments about wrongly placed braces or spaces from code review and can rather focus more on the content. But there will be still a need for some coding guidelines in other places (like auto usage, foreach and

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread André Somers
Op 16/03/2016 om 20:47 schreef Ziller Eike: On Mar 16, 2016, at 20:33, André Somers wrote: Op 16/03/2016 om 16:14 schreef Koehne Kai: Hi there, We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Jędrzej Nowacki
On Friday 18 of March 2016 09:13:13 Knoll Lars wrote: > I’m all for an automated solution for code formatting, so we can remove > discussions/comments about wrongly placed braces or spaces from code review > and can rather focus more on the content. But there will be still a need > for some coding

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Thiago Macieira
On quinta-feira, 17 de março de 2016 15:57:23 PDT Koehne Kai wrote: > > If I recommend the Qt coding style to a customer, he'll come back and say > > "How do I open this?". > > How do they open a .qdoc file? They probably don't, but browse the > generated .html documentation. The same can be

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Knoll Lars
On 17/03/16 00:14, "Development on behalf of Thiago Macieira" wrote: >On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote: >> Good initiative. I think this is the right idea.

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread André Somers
Op 17/03/2016 om 11:24 schreef Mathias Hasselmann: Am 17.03.2016 um 10:01 schrieb Sorvig Morten: How about treating the coding guidelines as \internal documentation? We could then at some point build and publish it together with the rest of the \internal's. (suitably separated from the

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Mathias Hasselmann
Am 17.03.2016 um 10:01 schrieb Sorvig Morten: How about treating the coding guidelines as \internal documentation? We could then at some point build and publish it together with the rest of the \internal's. (suitably separated from the public user documentation) Actually having the Qt code

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Richard Moore
On 16 March 2016 at 21:43, Knoll Lars wrote: > Good initiative. I think this is the right idea. Let's put the coding > guidelines into .qdoc files after having a decision on the ML. > > We should actually consider having a section about contributing to Qt in > our

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Konstantin Tokarev
17.03.2016, 20:23, "Giuseppe D'Angelo" : > Il 17/03/2016 18:09, Welbourne Edward ha scritto: >>  There is also an "eat our own dog-food" argument somewhere here: we ask >>  developers to document their code in qdoc, so we should be happy to use >>  it ourselves, even

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Giuseppe D'Angelo
Il 17/03/2016 18:09, Welbourne Edward ha scritto: There is also an "eat our own dog-food" argument somewhere here: we ask developers to document their code in qdoc, so we should be happy to use it ourselves, even for not-quite-code things. The question is, can/should we get the HTML output of

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Mandeep Sandhu
On Thu, Mar 17, 2016 at 3:24 AM, Mathias Hasselmann wrote: > > > Am 17.03.2016 um 10:01 schrieb Sorvig Morten: >> >> How about treating the coding guidelines as \internal documentation? >> We could then at some point build and publish it together with the >> rest of the

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Knoll Lars
On 18/03/16 16:03, "Development on behalf of Marc Mutz" wrote: >On Friday 18 March 2016 15:37:40 André Somers wrote: >> Op 18/03/2016 om 09:24 schreef Rutledge Shawn: >> > Forcing it on everyone

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Knoll Lars
Good initiative. I think this is the right idea. Let's put the coding guidelines into .qdoc files after having a decision on the ML. We should actually consider having a section about contributing to Qt in our documentation. Coding guidelines would fit nicely into that. But I think the .qdoc

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Marc Mutz
On Thursday 17 March 2016 08:37:38 Knoll Lars wrote: > On 17/03/16 00:14, "Development on behalf of Thiago Macieira" wrote: > >On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote: > >> Good initiative. I think this is the right idea. Let's put the coding > >> guidelines into .qdoc

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Sergio Martins
On Thursday, March 17, 2016 02:30:03 PM Koehne Kai wrote: (snip) > Completely orthogonal to this is though in which format the documents > are. You're specifically mentioning .qdoc, but I assume it wouldn't really > matter if it's Markdown (from the 'reusability' perspective)? If we keep these

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Thiago Macieira
On quarta-feira, 16 de março de 2016 20:56:42 PDT André Somers wrote: > Doesn't that lead to having the discussion twice: first once in the ML, > then again in the MR for the change? The ML is the ultimate decider, so if we had consensus on the list, that's that. The discussion in the change

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Thiago Macieira
On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote: > Good initiative. I think this is the right idea. Let's put the coding > guidelines into .qdoc files after having a decision on the ML. As I said, there is already a change by Marc that adds this file (it was an .md instead of

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Thiago Macieira
On quarta-feira, 16 de março de 2016 15:14:24 PDT Koehne Kai wrote: > Hi there, > > We have had quite some discussions about the use of C++11 features and right > API in the past on this mailing list - but if there has been a consensus > (which is sometimes hard to find out), it was often buried

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Welbourne Edward
Kai Koehne said: > I've been contemplating whether we should instead use some more > formalized decision process. We could have a document uploaded in git, > and every change needs to be reviewed and approved by Lars. This sounds like an eminently sensible way to document a consensus: we can have

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Koehne Kai
> -Original Message- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany@qt-project.org] On Behalf Of > Sergio Martins > Sent: Thursday, March 17, 2016 1:15 PM > To: development@qt-project.org > Subject: Re: [Development] Qt Coding Guidel

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Thiago Macieira
On sexta-feira, 18 de março de 2016 10:46:41 PDT Koehne Kai wrote: > > It remains that this document is expected to be quite stable, so there > > would be some sense to having a stable URL to which we routinely copy the > > new version once a change to the source has been accepted. The effort > >

Re: [Development] Qt Coding Guidelines

2016-03-19 Thread Giuseppe D'Angelo
Il 17/03/2016 18:58, Konstantin Tokarev ha scritto: What's wrong with reading them as plain text? What's the point at using a markup format then? (And cf. the proposal of having the guidelines available somewhere easily, to point people to them.) Cheers, -- Giuseppe D'Angelo |

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Giuseppe D'Angelo
Il 16/03/2016 16:14, Koehne Kai ha scritto: We already have the coding conventions page:https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Filippo Cucchetto
+1 Il 16/mar/2016 16:14, "Koehne Kai" ha scritto: > Hi there, > > We have had quite some discussions about the use of C++11 features and > right API in the past on this mailing list - but if there has been a > consensus (which is sometimes hard to find out), it was

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Sergio Martins
(snip) On Friday, March 18, 2016 08:48:52 AM Jedrzej Nowacki wrote: > So I think, that we should not discuss what is better qdoc or md. The real > discussion is about tooling, what is the best tool to sanitize Qt code. This thread is derailing. Kai wants to move a few wiki documents to git,

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Sorvig Morten
> On 18 Mar 2016, at 08:48, Jędrzej Nowacki > wrote: > > So I think, that we should not discuss what is better qdoc or md. The real > discussion is about tooling, what is the best tool to sanitize Qt code. We > need something that: > 1. Can work as a sanity

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Marc Mutz
On Friday 18 March 2016 17:05:37 Knoll Lars wrote: > On 18/03/16 16:03, "Development on behalf of Marc Mutz" wrote: > >On Friday 18 March 2016 15:37:40 André Somers wrote: > >> Op 18/03/2016 om 09:24 schreef Rutledge Shawn: > >> > Forcing it on everyone that way will be controversial, because

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Koehne Kai
> -Original Message- > From: Development [mailto:development- > [...] > It remains that this document is expected to be quite stable, so there would > be some sense to having a stable URL to which we routinely copy the new > version once a change to the source has been accepted. The

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Welbourne Edward
Giuseppe D'Angelo: >>> The question is, can/should we get the HTML output of these documents >>> published somewhere, for ease of access? All the HTML generated from QDoc in all of our code should be visible in some public way. This would just be one more page of that. >>> Do they need their

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Marc Mutz
On Friday 18 March 2016 23:45:22 Marc Mutz wrote: > On Friday 18 March 2016 17:05:37 Knoll Lars wrote: > > On 18/03/16 16:03, "Development on behalf of Marc Mutz" > bounces+lars.knoll=theqtcompany@qt-project.org on behalf of > > marc.m...@kdab.com> wrote: > > >On Friday 18 March 2016

Re: [Development] Qt Coding Guidelines

2016-03-18 Thread Rutledge Shawn
On 18 Mar 2016, at 08:48, Jędrzej Nowacki > wrote: Every time someone discuss coding style issues my blood boils. I understand that it is important to have consistent coding style, but discussing where to put braces or