Re: [Development] [closed] Using semicolons in JS (QML)

[André Somers]

So, now we need one of these QUIPs to document the descision if I 
understand it correctly ?


André


Op 06/10/2016 om 10:58 schreef Mitch Curtis:

To make it a bit more formal and hopefully prevent it from being lost in the 
mail archives, let's update our QML coding conventions:

https://codereview.qt-project.org/#/c/173027/


-Original Message-
From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
project.org] On Behalf Of Kai Koehne
Sent: Wednesday, 5 October 2016 3:23 PM
To: Viktor Engelmann ; development@qt-
project.org
Subject: [Development] [closed] Using semicolons in JS (QML)

Hi,

Alright, to close this thread: It seems the majority agrees that using
semicolons after JS statement inside a Javascript {} block is a good idea. The
suggestion is to follow this in new code. Personally, I will point out missing ;
as defects in reviews.

Regards

Kai


-Original Message-
From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
project.org] On Behalf Of Viktor Engelmann
Sent: Tuesday, October 04, 2016 3:51 PM
To: development@qt-project.org
Subject: Re: [Development] Using semicolons in JS (QML)

Am 30.09.2016 um 17:43 schrieb Shawn Rutledge:


Back in Nokia times it was said that we shouldn't use semicolons,
because it would speed up the parsing [...]


As someone who has written countless parsers, I *highly* doubt that
this is actually true. Indenting with tabs was also believed to be
*much* slower than indenting with spaces (which makes absolutely no
sense), and that measurement result turned out to be caused by a bug
in firebird. I bet this is also just an urban legend. Someone probably
thought "hey - one less character to read - must be faster to load",
but as André pointed out, the error recovery will most likely cost
more than what you save. Unless if the behavior is baked into the LR(1)

state-graph maybe.

Also I don't think it is good style to write code that doesn't conform
to the actual language, just because *most* parsers correctly *guess*
what you meant *most* of the time (except in those pathological
cases...). I think that you should *always* tell parsers *precisely*
what you mean and don't rely on it's guessing ability. For reference:
The Mariner 1 crash (which cost $80
million) was supposedly caused by an error that could have been caught
by static analysis at compile time, but was just "guessed away" wrongly.


Anyhow, I believe that we have spent more time on this debate than
will ever be saved by omitting semicolons.


Viktor


--



Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
viktor.engelm...@qt.io 
+49 151 26784521
http://qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B    




  
Qt World Summit 2016 | Pier 27, San Francisco, CA Experience
Exponential Potential on October 18-20 www.qtworldsummit.com


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [closed] Using semicolons in JS (QML)

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of André Somers
> Sent: Thursday, October 06, 2016 11:11 AM
> To: development@qt-project.org
> Subject: Re: [Development] [closed] Using semicolons in JS (QML)
> 
> So, now we need one of these QUIPs to document the descision if I
> understand it correctly ?

Ideally, yes. But I won't spend the time on writing a full QUIP for QML coding 
conventions, at least not now.

(Though I think there should be one, so if there are volunteers ... ;)

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [closed] Using semicolons in JS (QML)

[Mitch Curtis]

To make it a bit more formal and hopefully prevent it from being lost in the 
mail archives, let's update our QML coding conventions:

https://codereview.qt-project.org/#/c/173027/

> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Kai Koehne
> Sent: Wednesday, 5 October 2016 3:23 PM
> To: Viktor Engelmann ; development@qt-
> project.org
> Subject: [Development] [closed] Using semicolons in JS (QML)
> 
> Hi,
> 
> Alright, to close this thread: It seems the majority agrees that using
> semicolons after JS statement inside a Javascript {} block is a good idea. The
> suggestion is to follow this in new code. Personally, I will point out 
> missing ;
> as defects in reviews.
> 
> Regards
> 
> Kai
> 
> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > project.org] On Behalf Of Viktor Engelmann
> > Sent: Tuesday, October 04, 2016 3:51 PM
> > To: development@qt-project.org
> > Subject: Re: [Development] Using semicolons in JS (QML)
> >
> > Am 30.09.2016 um 17:43 schrieb Shawn Rutledge:
> >
> >
> > Back in Nokia times it was said that we shouldn't use semicolons,
> > because it would speed up the parsing [...]
> >
> >
> > As someone who has written countless parsers, I *highly* doubt that
> > this is actually true. Indenting with tabs was also believed to be
> > *much* slower than indenting with spaces (which makes absolutely no
> > sense), and that measurement result turned out to be caused by a bug
> > in firebird. I bet this is also just an urban legend. Someone probably
> > thought "hey - one less character to read - must be faster to load",
> > but as André pointed out, the error recovery will most likely cost
> > more than what you save. Unless if the behavior is baked into the LR(1)
> state-graph maybe.
> >
> > Also I don't think it is good style to write code that doesn't conform
> > to the actual language, just because *most* parsers correctly *guess*
> > what you meant *most* of the time (except in those pathological
> > cases...). I think that you should *always* tell parsers *precisely*
> > what you mean and don't rely on it's guessing ability. For reference:
> > The Mariner 1 crash (which cost $80
> > million) was supposedly caused by an error that could have been caught
> > by static analysis at compile time, but was just "guessed away" wrongly.
> >
> >
> > Anyhow, I believe that we have spent more time on this debate than
> > will ever be saved by omitting semicolons.
> >
> >
> > Viktor
> >
> >
> > --
> >
> >
> >
> > Viktor Engelmann
> > Software Engineer
> >
> > The Qt Company GmbH
> > Rudower Chaussee 13
> > D-12489 Berlin
> > viktor.engelm...@qt.io 
> > +49 151 26784521
> > http://qt.io
> >
> > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der
> > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
> > 144331 B    
> > 
> > 
> > 
> > 
> >  
> > Qt World Summit 2016 | Pier 27, San Francisco, CA Experience
> > Exponential Potential on October 18-20 www.qtworldsummit.com
> > 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtBase WIP branch request

[Oswald Buddenhagen]

On Wed, Oct 05, 2016 at 08:37:32PM +, Morten Sorvig wrote:
> We’re working on an update to the macOS/Cocoa platform plugin,
> and I would like to request a WIP branch where the changes can
> be finalized:
> 
>wip/remac
> 
you have Good Reasons (TM) for creating a branch according to
https://wiki.qt.io/Branch_Guidelines#Creating_a_new_feature_branch , yes?
mergable or throw-away?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtBase WIP branch request

[Oswald Buddenhagen]

On Thu, Oct 06, 2016 at 09:32:40PM +0800, Tim Blechmann wrote:
> >> We’re working on an update to the macOS/Cocoa platform plugin,
> >> and I would like to request a WIP branch where the changes can
> >> be finalized:
> >>
> >>wip/remac
> >>
> > you have Good Reasons (TM) for creating a branch according to
> > https://wiki.qt.io/Branch_Guidelines#Creating_a_new_feature_branch , yes?
> 
> i'm experiencing many of the issues that this branch will address (and
> hacked around them in my own version of the cocoa platform plugin).
> having a branch which is easy to access would allow me test the changes
> in a real-world context.
> 
as the wiki explains, a gerrit review series is also a branch, so you
can just check it out.

the one thing the wiki doesn't mention (but probably should): why do you
want to branch _at all_? i can think of two valid reasons:
- the work is experimental and may end up being discarded wholesale. in
  this case, having it in a separate branch is cleaner than reverts on
  the mainline.
- the development will take a long/unpredictable time, and you don't
  want the unfinished parts to be in mainline for the time being, as per
  feature integration policy.

the one thing that is definitely *not* a good reason: there may be
dysfunctional intermediate states. nope, you don't get to violate
atomicity just because you're on a branch.

of course, if you just want to be sloppy and are fine with a throw-away
branch, all the power to you.

> tia!
> tim
> 
> > mergable or throw-away?
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about keyboard mapping

[Randall OReilly]

Is this not incorporated into the main Qt codebase?  If not, why not?  I 
encountered a similar problem with the Mac Xserver in an earlier version of Qt 
(I think the first “fallback” fixed that but seems like this is a much more 
robust solution?).  Cheers,

- Randy

> On Oct 6, 2016, at 8:50 AM, Frank Richter  wrote:
> 
> Hi,
> I think what happened is that at some point keyboard handling on X11 was 
> changed to use xkb exclusively.
> This works fine if the server provides the xkb layout identity; this usually 
> is the case for non-ancient(?) X.org servers, but not necessarily for other 
> server vendors.
> Now, if that identity can not be determined, a fallback is used; still an xkb 
> keyboard layout from the local machine.
> Unfortunately, the "other" servers mentioned above may not use key codes that 
> match those from the local fallback layout, and you end up with weird 
> behaviour.
> (In my case it happened with Exceed, and keys were sort of "one off": you 
> pressed a key, but what appeared on screen was an adjacent letter...)
> 
> Anyway, the "solution" was to evaluate the keyboard mapping available through 
> the core protocol, and synthesize an xkb layout from that. This allows 
> keyboard input to work even if the server doesn't support xkb. You can find 
> patches here: https://github.com/res2k/QtLegacyXKeyboard
> 
> Hope I could help,
> -f.r.
> 
> On Mon, 3 Oct 2016 at 21:16 Scott Aron Bloom  wrote:
> I have had a bunch of customers report that using our tool over Xceed, 
> ASTEX-X, and now XManager, are having problems with the keyboard mapping.
> 
> Was there something fixed post Qt 5.5.1 for this type of issue?  I am stuck 
> on 5.5.1 for the near future, and will have to back patch it.
> 
>  
> 
> Scott
> 
> 
>  
> 
>  
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about keyboard mapping

[Frank Richter]

Hi,
I think what happened is that at some point keyboard handling on X11 was
changed to use xkb exclusively.
This works fine if the server provides the xkb layout identity; this
usually is the case for non-ancient(?) X.org servers, but not necessarily
for other server vendors.
Now, if that identity can not be determined, a fallback is used; still an
xkb keyboard layout from the local machine.
Unfortunately, the "other" servers mentioned above may not use key codes
that match those from the local fallback layout, and you end up with weird
behaviour.
(In my case it happened with Exceed, and keys were sort of "one off": you
pressed a key, but what appeared on screen was an adjacent letter...)

Anyway, the "solution" was to evaluate the keyboard mapping available
through the core protocol, and synthesize an xkb layout from that. This
allows keyboard input to work even if the server doesn't support xkb. You
can find patches here: https://github.com/res2k/QtLegacyXKeyboard

Hope I could help,
-f.r.

On Mon, 3 Oct 2016 at 21:16 Scott Aron Bloom  wrote:

> I have had a bunch of customers report that using our tool over Xceed,
> ASTEX-X, and now XManager, are having problems with the keyboard mapping.
>
> Was there something fixed post Qt 5.5.1 for this type of issue?  I am
> stuck on 5.5.1 for the near future, and will have to back patch it.
>
>
>
> Scott
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtBase WIP branch request

[Tim Blechmann]

>> We’re working on an update to the macOS/Cocoa platform plugin,
>> and I would like to request a WIP branch where the changes can
>> be finalized:
>>
>>wip/remac
>>
> you have Good Reasons (TM) for creating a branch according to
> https://wiki.qt.io/Branch_Guidelines#Creating_a_new_feature_branch , yes?

i'm experiencing many of the issues that this branch will address (and
hacked around them in my own version of the cocoa platform plugin).
having a branch which is easy to access would allow me test the changes
in a real-world context.

tia!
tim

> mergable or throw-away?



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development