Re: [Development] Neat feature in gerrit: drafts
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
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?
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?
> On Nov 10, 2016, at 6:08 AM, Marco Martinwrote: > > 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
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
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
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?
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
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
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
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
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
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
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?
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
> On 8 Nov 2016, at 15:57, Niccolò Belliwrote: > > 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
> On 9 Nov 2016, at 23:25, Allan Sandfeld Jensenwrote: > > > 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
> On 9 Nov 2016, at 19:44, Niccolò Belliwrote: > >> 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
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?
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
> On 4 Nov 2016, at 13:00, Robert Iakobashviliwrote: > > 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
> -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