Jeremy Whiting ha scritto:
> Are we suggesting the opposite for
> that section at least? Should we put together a Frameworks coding
> policy (since kdelibs coding policy is what is documented there, but
> frameworks aren't kdelibs) or update that page to what we suggest for
> frameworks coding poli
Hey all,
In updating some frameworks I took a look at the kdelibs coding style
(Is there a frameworks coding style, if not maybe it should be
created?) and especially the Qt Includes section seems a bit backwards
from what I see in actual code in frameworks.
https://techbase.kde.org/Policies
On Saturday 29 December 2012 14:50:46 Allen Winter wrote:
> On Saturday 29 December 2012 07:11:17 PM Martin Gräßlin wrote:
> > On Saturday 29 December 2012 16:25:54 Albert Astals Cid wrote:
> > > Would there be any chance to have the style check done by a pre-commit
> > > hook? Or at least have a c
On Saturday 29 December 2012 21:56:41 Thiago Macieira wrote:
> On domingo, 30 de dezembro de 2012 00.48.01, Stephen Kelly wrote:
> > >> Out of curiosity, is it something which got documented in the Qt
> > >> project?
> > >> Or that's more a custom? (doesn't make it less valid, I'm being curious
> >
On domingo, 30 de dezembro de 2012 00.48.01, Stephen Kelly wrote:
> >> Out of curiosity, is it something which got documented in the Qt project?
> >> Or that's more a custom? (doesn't make it less valid, I'm being curious
> >> here and couldn't find the info)
> >
> > syncqt complains if public head
Thiago Macieira wrote:
> On sábado, 29 de dezembro de 2012 22.58.49, Kevin Ottens wrote:
>> On Saturday 29 December 2012 11:06:30 David Faure wrote:
>> > Well, for frameworks that intend to be "as close to Qt as possible"
>> > they should do the same (for the convenience of developers who don't
>>
On sábado, 29 de dezembro de 2012 22.58.49, Kevin Ottens wrote:
> On Saturday 29 December 2012 11:06:30 David Faure wrote:
> > Well, for frameworks that intend to be "as close to Qt as possible" they
> > should do the same (for the convenience of developers who don't use
> > qmake/cmake but set up
On Saturday 29 December 2012 11:06:30 David Faure wrote:
> Well, for frameworks that intend to be "as close to Qt as possible" they
> should do the same (for the convenience of developers who don't use
> qmake/cmake but set up their project configuration in their IDE by hand, for
> instance Visual
from one module to another) it sounds like it's the right move to
> > drop them completely and use only the class name for includes[*].
> >
> > > Will kde-frameworks be Qt5-only, so not need to support both Qt4 and Qt5
> > > and thus to use module-less Qt includes?
> &
On Sat, Dec 29, 2012 at 7:50 PM, Allen Winter wrote:
>
> If you have the Krazy command line tool installed (
> https://gitorious.org/krazy)
> then you could write a pre-commit hook that runs 'krazy2 --style' on the
> files
> being committed.
>
./krazy2 --style
Unknown option: style
Besides, it
On Saturday 29 December 2012 19:11:17 Martin Gräßlin wrote:
> On Saturday 29 December 2012 16:25:54 Albert Astals Cid wrote:
> > Would there be any chance to have the style check done by a pre-commit
> > hook? Or at least have a command-line tool that checks it for me?
>
> yeah that should be possi
On Saturday 29 December 2012 07:11:17 PM Martin Gräßlin wrote:
> On Saturday 29 December 2012 16:25:54 Albert Astals Cid wrote:
> >
> > Would there be any chance to have the style check done by a pre-commit hook?
> > Or at least have a command-line tool that checks it for me?
> yeah that should be
On Saturday 29 December 2012 16:25:54 Albert Astals Cid wrote:
>
> Would there be any chance to have the style check done by a pre-commit hook?
> Or at least have a command-line tool that checks it for me?
yeah that should be possible. At my old day-job I created a pre-commit hook to
basically gr
On Saturday, December 29, 2012 04:25:54 PM Albert Astals Cid wrote:
> Would there be any chance to have the style check done by a pre-commit hook?
> Or at least have a command-line tool that checks it for me?
Wouldn't that typically be a Krazy thing to check (and you can run Krazy
checks from the
ther) it sounds like it's the right move to
> drop them completely and use only the class name for includes[*].
>
> > Will kde-frameworks be Qt5-only, so not need to support both Qt4 and Qt5
> > and thus to use module-less Qt includes?
>
> For now it supports both,
nclude
statements.
> So will projects which refer to the Kdelibs Coding Style need to
> add an exception to their rules for the includes, if they want to prepare
> for Qt5?
> Or does the rule need adaption?
Well, for frameworks that intend to be "as close to Qt as possible" they
Kevin Ottens wrote:
> We should push to use the class name only includes I think.
I agree.
We have a buildsystem that is good enough that we can specify the
directories to look for the 'class name' headers in, and it is in the
buildsystem that that stuff belongs.
See the kinds of practical
e it's the right move to drop
them completely and use only the class name for includes[*].
> Will kde-frameworks be Qt5-only, so not need to support both Qt4 and Qt5 and
> thus to use module-less Qt includes?
For now it supports both, but it's very likely that by the end of january i
Hi,
what about adapting the Kdelibs Coding Style to the upcoming preparations for
the porting to Qt5? A lot of (KDE) projects follow that kdelibs one, but there
is (at least?) one rule which seems to conflict with the recommendations for
the preparations:
--- 8< ---
Qt Includes
If you
19 matches
Mail list logo
