Re: [Development] Neat feature in gerrit: drafts

[Tobias Hunger]

Hi Edward,

Am 10.11.2016 17:18 schrieb "Edward Welbourne" :
>
> A review puzzled several of us today by (apparently) starting at patch
> set 6.  Jesus had discovered a gerrit feature we hadn't heard of:
> drafts.  If you push to refs/drafts/blah instead of refs/for/blah, you
> get a review on gerrit with much of the effect we normally achieve using
> WIP but without the sanity-bot's complaint about WIP and without the
> buttons that would allow staging.  Folk can comment on it, they just
> can't actually accept it yet.  Later you can push to refs/for/blah as
> usual and the review turns into a real review.  Further pushes to
> refs/drafts/blah will be added as later patch sets without spamming
> those watching the review, while being visible to anyone actually
> looking at it; and you can delete drafts from the history once all they
> are is clutter.  There's probably more fun I've yet to learn.
>
> This seemed worth publicizing; so now you all know :-)

Qt Creator supports drafts, too.

You can also push a draft over an existing patch set in review. That draft
can then be discussed and "published" to become a "real" patch in the patch
set.

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

Re: [Development] Neat feature in gerrit: drafts

[Sergio Ahumada]

On 10.11.2016 17:20, Konstantin Tokarev wrote:



10.11.2016, 19:18, "Edward Welbourne" :

A review puzzled several of us today by (apparently) starting at patch
set 6. Jesus had discovered a gerrit feature we hadn't heard of:
drafts.


FYI, it was around for ages, since 2.3 release


git-gpush has it since 2014

https://codereview.qt-project.org/88136


If you push to refs/drafts/blah instead of refs/for/blah, you
get a review on gerrit with much of the effect we normally achieve using
WIP but without the sanity-bot's complaint about WIP and without the
buttons that would allow staging. Folk can comment on it, they just
can't actually accept it yet. Later you can push to refs/for/blah as
usual and the review turns into a real review. Further pushes to
refs/drafts/blah will be added as later patch sets without spamming
those watching the review, while being visible to anyone actually
looking at it; and you can delete drafts from the history once all they
are is clutter. There's probably more fun I've yet to learn.

This seemed worth publicizing; so now you all know :-)

Eddy.



--
Sergio Ahumada
sahum...@texla.cl

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

Re: [Development] QtQuickControls for desktop: what's the plan?

[Konstantin Tokarev]

10.11.2016, 17:08, "Marco Martin" :
> On Thursday 10 November 2016 11:11:35 Olivier Goffart wrote:
>>  Writing and polishing styles to pixel perfection is indeed lot of work. And
>>  QStyle has the advantage hat it already exists. However one can copy-paste
>>  the code to turn existing styles into QCC2 style. (You will have two style
>>  to maintain since QtWidgets is still maintained)
>>
>>  The proxy style to QStyle that Marco is developing is a good intermediate
>>  solution for people wanting to develop cross platform desktop applications,
>>  while waiting for proper native looking themes on each platform.
>
> yeah, I also see it more like as a temporary solution as well, if not else for
> the fact that it can work only on QApplication instances.
> For us it's important to get in a short enough time span a good compelling
> reasons for applications to start using qtquickcontrols2, but I agree on the
> long run something else not linking to qwidgets is needed (which also speaks
> against official inclusion in Qt, as would get deprecated soon-ish in that 
> case)

Such deprecation would mean that users of 3rd-party QStyle themes will need to 
port
their themes away from QStyle to make QCC2 applications look native

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

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

Re: [Development] QtQuickControls for desktop: what's the plan?

[Jake Petroules]

> On Nov 10, 2016, at 6:08 AM, Marco Martin  wrote:
> 
> On Thursday 10 November 2016 11:11:35 Olivier Goffart wrote:
>> Writing and polishing styles to pixel perfection is indeed lot of work. And
>> QStyle has the advantage hat it already exists. However one can copy-paste
>> the code to turn existing styles into QCC2 style. (You will have two style
>> to maintain since QtWidgets is still maintained)
>> 
>> The proxy style to QStyle that Marco is developing is a good intermediate
>> solution for people wanting to develop cross platform desktop applications,
>> while waiting for proper native looking themes on each platform.
> 
> yeah, I also see it more like as a temporary solution as well, if not else 
> for 
> the fact that it can work only on QApplication instances.
> For us it's important to get in a short enough time span a good compelling 
> reasons for applications to start using qtquickcontrols2, but I agree on the 
> long run something else not linking to qwidgets is needed (which also speaks 
> against official inclusion in Qt, as would get deprecated soon-ish in that 
> case)

OK, I think that's a very reasonable assessment. After that, if you have any 
ideas around creating a proper long term solution for QQC2 that doesn't rely on 
QStyle, we'd love to hear them! Patches are welcome as well. :)

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

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

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

Re: [Development] Neat feature in gerrit: drafts

[Konstantin Tokarev]

10.11.2016, 19:18, "Edward Welbourne" :
> A review puzzled several of us today by (apparently) starting at patch
> set 6. Jesus had discovered a gerrit feature we hadn't heard of:
> drafts.

FYI, it was around for ages, since 2.3 release

> If you push to refs/drafts/blah instead of refs/for/blah, you
> get a review on gerrit with much of the effect we normally achieve using
> WIP but without the sanity-bot's complaint about WIP and without the
> buttons that would allow staging. Folk can comment on it, they just
> can't actually accept it yet. Later you can push to refs/for/blah as
> usual and the review turns into a real review. Further pushes to
> refs/drafts/blah will be added as later patch sets without spamming
> those watching the review, while being visible to anyone actually
> looking at it; and you can delete drafts from the history once all they
> are is clutter. There's probably more fun I've yet to learn.
>
> This seemed worth publicizing; so now you all know :-)
>
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Development] Neat feature in gerrit: drafts

[Edward Welbourne]

A review puzzled several of us today by (apparently) starting at patch
set 6.  Jesus had discovered a gerrit feature we hadn't heard of:
drafts.  If you push to refs/drafts/blah instead of refs/for/blah, you
get a review on gerrit with much of the effect we normally achieve using
WIP but without the sanity-bot's complaint about WIP and without the
buttons that would allow staging.  Folk can comment on it, they just
can't actually accept it yet.  Later you can push to refs/for/blah as
usual and the review turns into a real review.  Further pushes to
refs/drafts/blah will be added as later patch sets without spamming
those watching the review, while being visible to anyone actually
looking at it; and you can delete drafts from the history once all they
are is clutter.  There's probably more fun I've yet to learn.

This seemed worth publicizing; so now you all know :-)

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

Re: [Development] Change file process & improvement proposal

[Oswald Buddenhagen]

On Thu, Nov 10, 2016 at 12:38:41PM +, Jani Heikkinen wrote:
> Lately it has been quite hard to get change files done for the releases.
>
oh, it's that time of the year again. :D

> 1) Let's enable [ChangeLog] -tag by default in commit template. After
> that you must remove/comment out it by purpose if you don't want add
> it.
>
i really don't think this will make a positive difference. the problem
is that many people just don't have the right audience-oriented mindset.
we *already* have lots of garbage changelog entries, and this will just
worsen the S/N ratio.

> And in addition to this update sanity bot so that it will give '-1' if
> change log entry isn't given in release branch.
>
this is probably not sensible. most last-minute fixes relate to recently
introduced problems, which means that they specifically *don't* need
changelog entries.

here's what i think would actually make a difference (based on
historical evidence within trolltech):
https://bugreports.qt.io/browse/QTQAINFRA-933

> 2) Let's agree every submodule in the release needs to have a change
> file (to make things clear)
> 
yes

> 3) Let's agree the change log is the diff between new & previous
> release in same series (in case of patch level release, meaning delta
> from x.y.z -> x.y.z+1). And for new major release the diff is from
> last patch release from previous series
> 
that seems a no-brainer to me. the tricky question is what to do with
LTS vs. stable, but we already resolved this: we duplicate the relevant
log entries.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuickControls for desktop: what's the plan?

[Marco Martin]

On Thursday 10 November 2016 11:11:35 Olivier Goffart wrote:
> Writing and polishing styles to pixel perfection is indeed lot of work. And
> QStyle has the advantage hat it already exists. However one can copy-paste
> the code to turn existing styles into QCC2 style. (You will have two style
> to maintain since QtWidgets is still maintained)
> 
> The proxy style to QStyle that Marco is developing is a good intermediate
> solution for people wanting to develop cross platform desktop applications,
> while waiting for proper native looking themes on each platform.

yeah, I also see it more like as a temporary solution as well, if not else for 
the fact that it can work only on QApplication instances.
For us it's important to get in a short enough time span a good compelling 
reasons for applications to start using qtquickcontrols2, but I agree on the 
long run something else not linking to qwidgets is needed (which also speaks 
against official inclusion in Qt, as would get deprecated soon-ish in that case)

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

Re: [Development] Problems compiling QtWebEngine in 5.8.0 beta

[Harald Vistnes]

FYI, using a shorter folder name solved the problem.

Thanks for your help.

Harald

2016-11-10 10:58 GMT+01:00 Edward Welbourne :

> > I've started a new build in a folder with a shorter name
>
> Good luck,
>
> Eddy.
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Jędrzej Nowacki]

On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote:
> the easiest would be going with the normal approval rights, but limit
> the submit button to a "QUIP owners" group which would consist of lars
> (and possibly a _few_ deputies).

Considering expected traffic there it could be only Lars :-)

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Change file process & improvement proposal

[Jani Heikkinen]

Hi all,

Lately it has been quite hard to get change files done for the releases. It 
should be maintainers responsibility to make sure those will be done for every 
release and those are containing proper data. We have tried to help maintainers 
by doing initial ones for them (running script to collect all changes 
containing [ChangeLog] -tag).

Unfortunately it seems that tag is really rarely used (at least in most of 
modules) even there is lots of changes in:( In my opinion (almost) all changes 
in patch level release should be worth of change file entry: If change isn't 
critical enough for change file entry does it belong in patch level release at 
all? Could we change our template/sanitybot so that it encourage developers to 
add change file entries more often and forces them to do it in release branches?

One unclear issue related to change files is when we should have one? Should we 
create one only if there really is some critical changes in the submodule or 
should we create one in any case? I think the latter one could be more clear 
one: In first case it is unclear why one is missing? Is it because maintainer 
hasn't done his job or just because there isn't important changes to be 
mentioned? In latter case there is that change file for every release and it 
contains info if there is important changes or not.

And another issue is the 'base release' for change files. Someones seems to 
think change files should contain diff from previous official release (meaning 
5.7.1 change files should contain delta from 5.6.2) and others that diff should 
be from previous release of same series (meaning 5.7.1 change files should 
contain delta from 5.7.0). I have thought it is latter one and created initial 
ones based on that assumption.

So I propose:

1) Let's enable [ChangeLog] -tag by default in commit template. After that you 
must remove/comment out it by purpose if you don't want add it. And in addition 
to this update sanity bot so that it will give '-1' if change log entry isn't 
given in release branch. This can be bypassed by giving '+1' manually for 
sanity review if really needed... That way we could get more ready change files 
directly by running script and so on less work for maintainer.

2) Let's agree every submodule in the release needs to have a change file (to 
make things clear)

3) Let's agree the change log is the diff between new & previous release in 
same series (in case of patch level release, meaning delta from x.y.z -> 
x.y.z+1). And for new major release the diff is from last patch release from 
previous series


Jani Heikkinen
Release Manager
The Qt Company






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

Re: [Development] cdn.qt.digia.com SSL certificate has expired

[Jędrzej Nowacki]

On torsdag 10. november 2016 11.39.14 CET Arnaud Vrac wrote:
> Hi,
> 
> I'm trying to run MaintenanceTool on my Qt commercial install and it fails,
> apparently because the SSL certificate to cdn.qt.digia.com has expired.
> This also prevents using the online installer.
> 
> Can this please be fixed ?
> 
> Thanks,
> 
> -Arnaud

I have forwarded this email to our IT. Should be fixed soon.

Thanks,
   Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] cdn.qt.digia.com SSL certificate has expired

[Arnaud Vrac]

Hi,

I'm trying to run MaintenanceTool on my Qt commercial install and it fails,
apparently because the SSL certificate to cdn.qt.digia.com has expired.
This also prevents using the online installer.

Can this please be fixed ?

Thanks,

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Oswald Buddenhagen]

On Wed, Nov 09, 2016 at 06:49:08PM +, Edward Welbourne wrote:
> > Agree with meta/quips
> 
> +1,
> 
the repository has been created.

next point: permissions.
i don't think the regular ones are appropriate - they are way too
anarchic for a process that is supposed to reflect *actual* community
consensus.
the easiest would be going with the normal approval rights, but limit
the submit button to a "QUIP owners" group which would consist of lars
(and possibly a _few_ deputies).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuickControls for desktop: what's the plan?

[Olivier Goffart]

On Donnerstag, 10. November 2016 09:55:00 CET Frederik Gladhorn wrote:
> Hello all,
> let's take a step back and get back into a productive discussion :)
> 
> I'm sorry that Jake uses so harsh words and I hope everyone understands he
> expresses his personal opinion since he's not even directly involved in the
> Qt Quick Controls (1/2) project.

Thanks for the apology.
(It's a bit rude to demand that someone contribute for free to someone else's 
commercial product.)

> Yesterday we had some debate here in Oslo about what is needed for controls
> in the near future and where we see things heading. [...]
> We have researched an iOS style [...] macOS is another candidate where we're
> starting to look.

Great to hear that you are looking at the desktop again.

Also... don't forget Windows and GTK+ styles.

> The situation with KDE is actually quite interesting, since the platform is
> QStyle based. 

It does not have to be. I believe there will be an QQC2 Oxygen style soon 
enough.

> We do not believe in QStyle based styles for QQC2 as it stands. They will
> never have the same performance level of the other styles. þ...]

Regarding performance maybe it's good enough for desktop. But there are other 
reasons why QStyle might not be desirable: dependency on QtWidget and alien 
abstraction.

> Maybe we in the end conclude that it's all too much work and we want to have
> a QStyle based theme in controls 2, but let's first explore the options.

Writing and polishing styles to pixel perfection is indeed lot of work. And 
QStyle has the advantage hat it already exists. However one can copy-paste the 
code to turn existing styles into QCC2 style. (You will have two style to 
maintain since QtWidgets is still maintained)

The proxy style to QStyle that Marco is developing is a good intermediate 
solution for people wanting to develop cross platform desktop applications, 
while waiting for proper native looking themes on each platform.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [HiDPI] Rethinking the scaling algorithm

[Morten Sorvig]

> On 8 Nov 2016, at 15:57, Niccolò Belli  wrote:
> 
> Hi,
> My laptop's monitor is a 13" with a 16:9 aspect ratio and a 3200x1800 
> resolution. As you can see[1] the EDID[2] is perfectly correct.
> QT computes the scaling factor using a formula like this: 
> scaling_factor=qRound(yourDpi/96)
> This is far from ideal in my opinion, because if we want to scale to 96 
> logical PPI it means that on a 13" 16:9 screen we want to target a 1088x612 
> logical resolution. In fact qRound(282.42/96) computes a 3x scaling factor 
> for my laptop, which is not a scaling factor that *anybody* would like to 
> have (except maybe my old grandfather with poor eyesight). In fact a logical 
> resolution of *less* than 1088x612 (it's lesser because qRound actually 
> rounded up the value) is too tiny even for a 13" screen and people would 
> prefer a 2x scaling factor instead, which would give you a logical resolution 
> of 1600x900 (instead of an useless 1067x600).
> 
> I have some suggestions to improve the current scaling algorithm:
> 
> 1) Always round down. With your current formula a 145ppi screen gets scaled 
> by a 2x factor, while every other toolkit (GTK3 for example[3]) starts 
> scaling at 192ppi. This is also what people expect and it would return the 
> correct 2x scaling factor for my laptop. So the formula should be 
> scaling_factor=qRoundDown(yourDpi/96)


Hi, thanks for bringing this up. I agree with this point; mathematically 
correct rounding
may not be the best kind of correct in this case.

In fact a change is already in review:

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

This introduces QT_SCALE_FACTOR_ROUNDING_POLICY with the following options:

Round  qRound(), as today
Ceil   qCeil()
Floor  qFloor()
RoundPreferFloor   Round up for .75 and higher
PassThroughDo not round and allow fractional scale factors

RoundPreferFloor is the new default. Do you think this is sufficient? Adding 
more options is
possible, as is adding a C++ API if needed. 

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

Re: [Development] [HiDPI] Rethinking the scaling algorithm

[Morten Sorvig]

> On 9 Nov 2016, at 23:25, Allan Sandfeld Jensen  wrote:
> 
> 
> Since most of the common configuration of HiDPI screens are following Mac 
> standards, they have been designed to work at 2x scaling with 72DPI. We can 
> not ignore all the Apple style screens out there like 4k 27" screen for 
> instance. Which are specifically designed for 2x scaling. 144DPI must cause 
> 2x 
> scaling to follow what most HiDPI hardware have been designed for.
> 
> What we need is a better tool and configuration for high-DPI tablets, phones 
> and hybrids where the ideal virtual DPI is not 72 or 96 DPI.

On the other hand, Windows 200% must also result in 2x scaling. And windows
will return 2 * 96 DPI for that case.

What I have in my patches is API where the platform plugin reports the base DPI
in addition to the current DPI. So in the Windows case the values would be 96
and 192, respectively. See https://codereview.qt-project.org/#/c/157174 .

In theory, a platform like Android could then return its base DPI of 160 along 
with the current DPI, and we would apply the correct scale factor according
to the device class. (In practice I think the Android platform plugin currently
normalizes the base DPI to 96)

Would this allow enough configurability to handle your 4K 27” case? We have user
API for setting the DPI (QT_FONT_DPI) as well, but this is currently a global
setter and not that useful for multi-screen setups.


Morten

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

Re: [Development] [HiDPI] Rethinking the scaling algorithm

[Morten Sorvig]

> On 9 Nov 2016, at 19:44, Niccolò Belli  wrote:
> 
>> On martedì 8 novembre 2016 23:34:48 CET, Allan Sandfeld Jensen wrote:
>>> We have a two factor scaling system. We also scale by DPI. 144/2 == 72 for 
>>> instance, which happens to be the standard on Macs. Therefore 144DPI become 
>>> a normal 2x scaling of standard 72 Mac DPI. And having 2x with smaller 
>>> text, is a lot better than 1x with large text on a 27" 4K desktop screen.
> 
> Unfortunately 4K 27" monitors are almost impossibile to scale well without 
> floating point scaling. The right resolution for a 27" monitor would be 5K, 
> but they are still too expensive and the current displayport/tuhnderbolt 
> ports don't have enough bandwidth to drive two of them.

Agreed, if you look at pixel density then 24” seems to be the best option for 
4K.
This gives a PPI of 186, which is close enough to for example the rMBP at 227 
PPI
to make 2x an option. (Even more so if you allow a slightly larger intended 
viewing
distance for the desktop monitor.)

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

Re: [Development] Problems compiling QtWebEngine in 5.8.0 beta

[Harald Vistnes]

Thanks for the input.

Creating a file named webcore_generated.HTMLImageElementOrHTMLVideoEle
mentOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.rsp in a shallow
folder was no problem.

However, if I try to create it in the folder where it should be generated:
D:\qt-everywhere-opensource-src-5.8.0-beta\qtwebengine\src\core\Release_x64\obj\src\3rdparty\chromium\third_party\WebKit\Source\core\gen\blink\bindings\core\v8

then Windows pops up an error message:
'Destination Path Too Long
The file name(s) would be too long for the destination folder...'

That complete path would be 270 characters, which is longer than the 260
characters maximum.

I've started a new build in a folder with a shorter name than
D:\qt-everywhere-opensource-src-5.8.0-beta,
so all paths should hopefully be less than 260 characters.

Harald


2016-11-10 9:50 GMT+01:00 Edward Welbourne :

> Harald Vistnes quoted an unhappy compiler:
> > ...\webcore_generated.HTMLImageElementOrHTMLVideoEle
> mentOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.rsp): Unable to
> create file. No such file or directory
>
> That's 110 bytes of file-name: does your file-system have a problem with
> names that long ?
> Try creating a file with that name and see what happens ...
> Not sure what to do if it refuses, but it's at least a diagnostic test,
>
> Eddy.
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuickControls for desktop: what's the plan?

[Frederik Gladhorn]

Hello all,
let's take a step back and get back into a productive discussion :)

I'm sorry that Jake uses so harsh words and I hope everyone understands he 
expresses his personal opinion since he's not even directly involved in the Qt 
Quick Controls (1/2) project.

Yesterday we had some debate here in Oslo about what is needed for controls in 
the near future and where we see things heading. I should have joined the 
discussion earlier, but I perfer to ponder things a bit before shouting out 
loud.

>From our point of view, one of the biggest show stoppers in the near future is 
the lack of table view support (which touches listview and related). This is a 
topic that keeps comming up and we want to get it right, since in qcc1 you 
could hardly have more than 10 columns without massive performance issues.
So the current focus for us is polishing what we have and looking at the lists 
and tables.

At the same time there seem to be three big gaps in styling.
We have researched an iOS style, there are some legal concerns around it since 
it's unclear what Apple allows in the app store, so that's somewhat on hold, 
maybe we'll just publish it without any guarantees (that it's viable to get 
apps on the store with it) since we cannot give any. In the mean time, using 
custom styles should be perfectly fine for the iOS case. Slightly ironic.

With that said, macOS is another candidate where we're starting to look. 
Again, Apple is not making it exactly easy by basically not providing public 
APIs, but we'll see what we end up with. Especially animations will be 
interesting. Any insights and help is of course appreciated.

The last gap are Linux styles. The situation with KDE is actually quite 
interesting, since the platform is QStyle based. We do not believe in QStyle 
based styles for QQC2 as it stands. They will never have the same performance 
level of the other styles. Changing QStyle is not exactly trivial either, but 
maybe we can find a way to make it efficent and share code. Maybe we in the end 
conclude that it's all too much work and we want to have a QStyle based theme 
in controls 2, but let's first explore the options. I don't know the code 
enough to have any kind of opinion at this point and I'd propose people that 
actually have better insights explore which way makes most sense.

Now we're back to where we started the discussion and I hope we'll find out how 
to cooperate best, inside or outside the controls repository.

Kind regards,
Frederik

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

Re: [Development] Dictation Issues with Qt-built software

[Morten Sorvig]

> On 4 Nov 2016, at 13:00, Robert Iakobashvili  wrote:
> 
> Right. Most users of dictation are people with learning or motoric 
> disabilities.
> 
> When these users are used to a certain pattern of platform-specific habits
> working for them, any other options to do the same could be seen as usability 
> issues
> breaking these habits.


Hi, after some further investigation and offline discussion (thanks Frederik!),
I think we’re closer to solving this:

Dictation input can be handled via our current input method support, where we
implement the NSTextInputClient protocol. As a matter fact this almost works
today (Qt 5.6): select text in a Qt text editor; starting dictation via the
fn key should now work.

So what we are looking at then is developing a bug fix to our NSTextInputClient 
protocol implementation to make dictation work in all cases.

Morten


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

Re: [Development] Problems compiling QtWebEngine in 5.8.0 beta

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Egor Pugin
> Sent: Wednesday, November 09, 2016 10:55 PM
> To: Harald Vistnes 
> Cc: development@qt-project.org
> Subject: Re: [Development] Problems compiling QtWebEngine in 5.8.0 beta
> 
> Probably file path is too long.
> MS improved situation since win10.1607 (up to 32k symbols) but almost
> every program today (even from MS) is not able to handle such paths.
> They require special handling.
> See https://msdn.microsoft.com/en-
> us/library/windows/desktop/aa365247(v=vs.85).aspx
> for more info.

Sigh. We've been tweaking webengine already in the past to use relative paths,
but it  seems we didn't succeed everywhere.

Yeah, please make sure that the checkout path for qtwebengine is not too deep.

Reggards

Kai


> I had same issues with cmake+msbuild invocations.
> 
> On 9 November 2016 at 23:46, Harald Vistnes 
> wrote:
> > Hi,
> >
> > I'm having problems compiling 5.8.0 beta from source. It fails when
> > making qtwebengine.
> >
> >
> > D:\qt-everywhere-opensource-src-5.8.0-
> beta\qtwebengine\src\3rdparty\ni
> > nja\ninja.exe
> > -C
> > D:/qt-everywhere-opensource-src-5.8.0-
> beta/qtwebengine/src/core/Releas
> > e_x64
> > ninja: Entering directory
> > `D:/qt-everywhere-opensource-src-5.8.0-
> beta/qtwebengine/src/core/Release_x64'
> > ninja: error:
> >
> WriteFile(obj\src\3rdparty\chromium\third_party\WebKit\Source\core\gen
> \blink\bindings\core\v8\webcore_generated.HTMLImageElementOrHTMLVi
> deoElementOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.
> rsp):
> > Unable to create file. No such file or directory
> >
> > ninja: build stopped: .
> > NMAKE : fatal error U1077:
> > 'D:\qt-everywhere-opensource-src-5.8.0-
> beta\qtwebengine\src\3rdparty\ninja\ninja.exe'
> > : return code '0x1'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '(' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> >
> > Environment:
> > Windows 10
> > VS2015 x64
> > Windows 10 SDK
> > ninja
> >
> > Any help would be appreciated.
> >
> > Thanks,
> > Harald
> >
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> 
> 
> 
> --
> Egor Pugin
> ___
> 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