Fwd: Global Shortcuts

[Andreas Hartmetz]

Am Donnerstag 06 März 2008 22:19:58 schrieb Michael Jansen:
> On Thursday 06 March 2008 19:03:13 Alex Merry wrote:
> > On Thursday 06 March 2008 17:28:57 Michael Jansen wrote:
> > > On Thursday 06 March 2008 17:56:15 Andreas Hartmetz wrote:
> > > > connect(
> > > >         foo, bar,
> > > >         baz, blah
> > > >        );
> > >
> > > Do the example correct
> > > connect(
> > >     this, SIGNAL()
> > >     that, SLOT()
> > >    )
> >
> > You can do that in two lines:
> >
> > connect(this, SIGNAL(),
> >              that, SLOT());
>
> If that's the preferred solution i will try to follow that rule. I just
> want to remark that i think my version is more readable and is easier to
> type.
> Using tabstop width of 4 i just have to do return and tab and 
> i'm set. The good thing here is connect has 7 characters so in that case it
> will kust be two tabs. But when connect is for example a function call with
> 4 5 characters I must type in a mix of tabs and chars. Thats why i allways
> break directly behind the opening parenthesis. My is typing wise the same
> whatever s ize tabstop is defined to be. I told you i developed my styles
> over some time
>
> :-).
>
> I like to discuss over developing guide lines. Have written some myself.
> But a s i said i don't care really. Developing for money means adhering to
> standards given. So no problem here.
>
> > I think that would be more in keeping with the spirit of the style
> > guidelines.
> >
> > > > Q_FOREACH (blah, blarg) //it's not in a public header!
> > >
> > > Explanation please. Q_FOREACH is an macro. Alternatives?
> >
> > foreach(blah, blarg)
> >
> > Q_FOREACH is necessary for public headers because they have to compile
> > with the compile-time switch that disables the "foreach" alias.
>
> I can't remember what an alias is in c++. Seem to have missed that thing.
> Just checked. foreach is an preprocessor macro too. Sorry i prefer to have
> my macros uppercase. If you show me an developing style guide who says i
> have to use the foreach version i will question it's sense but adhere. Else
> i keep usi ng the uppercase version.
>
If you read some KDE code you can see that it's common to use the lowercase 
versions of all the Qt macros that have lowercase versions - unless there is 
a strong reason not to. emit, forever (I use while (true) instead), foreach, 
signals, slots [in non-public headers] and maybe others.

> > > And judging from the code i stumbled over noone else in kde does to. I
> > > have se en each and every style possible. Included using tabs. That's
> > > the only coding style i care about. It's an absolute no.

We could have a great stupid flamewar here as I actually like tabs. I use 
spaces nowadays (rules are rules) and that works for me just as well.
Just imagine that you have a codebase using almost only spaces and some tabs 
in a few places (it's an old codebase). Now somebody checks in code using 
some obscure unicode space char instead of tabs or spaces because that is 
more readable for the coder in question - maybe it looks good in his editor. 
What would you think? You might even get a little angry and step on the toes 
of somebody you'd better offer a beer for fixing something you broke :)

> >
> > There's some low-level efforts to unify the coding style in kdelibs, at
> > least, and I think many people take the view that kdebase should try to
> > follow the same rules, simply because it's so central to KDE.
>
> Then make it clearer. And kill the rule that forbids removing tabs from
> source s you don't touch If it's ok to change these nonsense.
>
> I slightly annoyed. Not because someone said i could improve my code. The
> how is bad behavior in my opinion. Some of the things he thinks are bad are
> just laughable. Some of them weren't even my code. And judging for some of
> the sources i touched there are bigger problems in the code.
>
I really didn't mean to attack you. That is why I mentioned twice that the 
code is fine otherwise.
Apart from that, if you rework 2/3 of some file it is a good idea (or rather, 
it is more or less expected) to adapt the formatting of the remaining 1/3 to 
the standard coding style. You cannot be expected to know all of that right 
away and that's OK.

> For me there is only one question. Is the code readable and understandable.
> An d that has nothing to do where the brackets or parentheses are.
>
It is a good thing to format code the way people expect it to help their 
understanding.
I am pretty sure that if you asked a random selection of KDE hackers they 
would prefer reading code in kdelibs formatting over something never seen 
before. I can see the point of some formatting choices but they are 
completely nonstandard.

> Mike

Your work is very much appreciated - by me and, so we can assume, by everybody 
who was unhappy about the brokenness of the keys KCM.
Your code is good. To make it more understandable to rest of us you should 
however refrain from using your personal coding style especially if it is 
unlike any other. For extra points you can adjust the remaining bits and 
pieces when you almost rewrite something. Agree?