> On 11 Apr 2016, at 12:38, Ben Lau wrote:
>
> Hi,
>
> I am writing an image provider that read all the images to memory at startup.
> And I found that the behaviour is different from 5.5.1 to 5.6 in iOS. Seems
> that it is undocumented. I wonder is it an expected behaviour or a bug?
Hi, thi
> On 16 Mar 2016, at 22:43, Knoll Lars wrote:
>
> We should actually consider having a section about contributing to Qt in our
> documentation. Coding guidelines would fit nicely into that. But I think the
> .qdoc files should rather live in qtdoc instead of qtbase as most of the
> overview d
> On 18 Mar 2016, at 08:48, Jędrzej Nowacki
> wrote:
>
> So I think, that we should not discuss what is better qdoc or md. The real
> discussion is about tooling, what is the best tool to sanitize Qt code. We
> need something that:
> 1. Can work as a sanity bot
> 2. Can re-format the code by
> On 23 Feb 2016, at 18:00, Jon Mullen wrote:
>
> Hey
>
> I’m trying to figure out how far along the Qt Nacl code is and if I’m able to
> use it on the project I’m working on. I have the code built from the qtbase
> wip/nacl branch. However, when I go to run the example window_widgets none
> On 19 Feb 2016, at 10:44, Gunnar Sletta wrote:
>
> Now every piece of code needs to also know about device pixel ratio and that
> needs to passed down to image loaders, icon generators
This is essential complexity, not accidental complexity. With
high-DPI displays in use raster images now v
> On 19 Feb 2016, at 10:44, Gunnar Sletta wrote:
>
>
> One obvious usecase which always comes back to haunt is when those logical
> units need to be translated to actual pixels, such as when dealing with
> graphics. Up until some time ago, Something::size() was enough to decide the
> pixel d
> On 18 Feb 2016, at 15:24, Welbourne Edward
> wrote:
>
> To meet all the actual use cases, we need three different *kinds* of
> size for things:
> * fraction of the available display area - good for top-level
>sub-division of the space an app has at its disposal to work in;
> * physical
> On 18 Feb 2016, at 12:35, Nikita Krupenko wrote:
>
> 2016-02-18 12:50 GMT+02:00 Hausmann Simon :
>> (1) In order to make it really easy to scale "logical" pixels without having
>> to introduce your own context property or factor in a .qml file that you
>> multiply everywhere, we could turn t
> On 18 Jan 2016, at 11:02, René J.V. Bertin wrote:
>
>
> One thing that's really missing from Qt at the moment is a way for an
> application that is not the foreground application to post a window in the
> foreground (cf. also my thread on extending QProcess). To my knowledge this
> can on
> On 08 Jan 2016, at 12:56, René J. V. Bertin wrote:
>
> Sorvig Morten wrote:
>
>> But you seldom want to have two instances of (say) Mail running - you start
>> it, or bring the existing one to front. So kLSLaunchNewInstance does not
>> seems
>> that us
> On 08 Jan 2016, at 10:03, Ziller Eike wrote:
>
>
>> On Jan 7, 2016, at 10:14 PM, René J. V. Bertin wrote:
>>
>> Sorvig Morten wrote:
>>
>>> Another point: Isn't there a fundamental incompatibiity between
>>> LaunchServices
>>&
Hello!
> On 28 Dec 2015, at 21:50, Die Waldmanns wrote:
>
> (1) Support of fractional scaling (devicePixelRatio).
> This ratio is qreal, but in QT5.5 it nevertheless seems not be possible to
> set it to fractional values (I could get it only to 1.0,2.0,3.0 etc). In
> 5.6-beta1 the new environ
> On 18 Dec 2015, at 01:05, Corentin Jabot wrote:
>
> Having stumbled upon this issue very recently, here are my 2 cents.
> • Svg images should be devicePixelRatio aware without having to set a
> source size
> • Likewise, QQuickImageProvider should know about devicePixelRation,
> w
> On 15 Dec 2015, at 20:25, rpzrpz...@gmail.com wrote:
>
> Instead of worrying about @2x and @3x and trying to generate artwork in all
> of the sizes, would it not be advantageous
> to only use SVG vector format and allow the svg plugin to generate and scale
> at run-time a single svg file in t
> On 15 Dec 2015, at 22:16, Tim Blechmann wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Your thoughts on projects that use ONLY SVG image resources
> and not PNG/JPEG?
But the above:
1) already works
>>>
>>> kind of ... the above will rasterize
Hi,
I’d like to provide short update on the changes in this space, an also lay out
some plans and possibilities for the future. Thanks to everyone who has helped
out! New changes:
* @3x support landed, both for Qt Widgets and Qt Quick. Implemented as @Nx
support, with @9x as a maximum value.
*
> On 11 Nov 2015, at 01:40, Adam Light wrote:
>
> I built Qt 5.6 (latest from the 5.6 git branch as of this morning) and tested
> our application with the build on Windows 10. I'm calling
> QApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
> before the QApplication is created.
>
> I do
> On 28 Sep 2015, at 23:40, Thiago Macieira wrote:
>
> What if we add an extra rpath to Qt libs as @executable_path/../Frameworks?
> Would this make loading work?
>
> Jake, Morten: as a stop-gap, is there a configure-time switch to revert to
> the
> old behaviour? This change seems to be too
> On 17 Sep 2015, at 19:15, Dean Floyd wrote:
>
> Dear all,
>
> We have a project where we weak link our app against the Wacom framework
> which on MacOSX by default gets installed in:
>
> /Library/Frameworks/WacomMultiTouch.framework
>
> otool -L returns the following line for the Wacom lin
> On 15 Sep 2015, at 03:51, Thiago Macieira wrote:
>
> On Monday 14 September 2015 08:09:28 Sorvig Morten wrote:
>> Then the question is: which ones should QtGui link against? On other words
>> OpenGL usage is not confined to platform plugins only.
>>
>> To me
> On 13 Sep 2015, at 00:55, Thiago Macieira wrote:
>
> On Saturday 12 September 2015 18:16:54 René J. V. Bertin wrote:
>> Thiago Macieira wrote:
>>> Maybe we need two tests: one for OpenGL for XCB plugin (with GLX support)
>>> and one for OpenGL for the Cocoa plugin (AGL support).
>>
>> I think
> On 05 Sep 2015, at 15:39, René J. V. Bertin wrote:
>
> and I can indeed use `foo --style=kde` to start foo using the currently
> selected
> style for KDE applications. However:
>
> 1- simply setting KDEHOME to ~/.kde doesn't have any effect (it's not
> required
> for --style=kde to work e
Hi,
QWindowSystemInterface has recently gained the ability to return the “accepted"
status of events, that is whether Qt used the event or not. The intended use
case is Qt-as-a-plugin type scenarios, where we would like to propagate
unhandled events back to the host.
The top level visible API
> On 01 Sep 2015, at 18:50, René J.V. Bertin wrote:
>
> Hi,
>
> Qt4 and Qt5 both have a "feature" where holding down the Meta key (Command on
> OS X) while scrolling a view causes text in the view to zoom in or out. This
> also works with the 2-finger scroll that most trackpads provide nowada
> On 18 Aug 2015, at 07:46, Thiago Macieira wrote:
>
> On Monday 13 July 2015 18:44:40 Thiago Macieira wrote:
>> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote:
>>> The only compiler I currently know that will have problems with this is
>>> the Intel compiler on OS X when using libc++
We’ve now started the merge process of wip/highdpi to dev. The branch has been
squashed and several new changes have been posted to codereview.
The code changes can be roughly divided into four groups:
1) Revert the existing implementations in the xcb and windows platform
plugins
Hi,
I’m happy to announce that a work-in-progress port of Qt to the Chrome / Native
Client platform has now been pushed to the wip/nacl branch in QtBase. So far
development has been closed, but we are now ready to develop in the open and
also take contributions. My intention is to at some point
> On 08 Jun 2015, at 11:07, Marc Mutz wrote:
>
> On Friday 05 June 2015 10:11:27 Frederik Gladhorn wrote:
>> diff --git a/src/widgets/widgets/qmaccocoaviewcontainer_mac.h
>> b/src/widgets/widgets/qmaccocoaviewcontainer_mac.h index a98d30f..5920c1f
>> 100644
>> --- a/src/widgets/widgets/qmaccocoa
> On 09 Jun 2015, at 11:18, René J.V. Bertin wrote:
>
> On Tuesday June 09 2015 08:27:09 Sorvig Morten wrote:
>
>> I think it’s OK if other modules, and especially new modules, have stricter
>> requirements. Qt users can make a decision if the provided OS version
> On 05 Jun 2015, at 19:00, Sean Harmer wrote:
>
> On 05/06/2015 14:52, René J.V. Bertin wrote:
>> On Friday June 05 2015 13:30:58 Sean Harmer wrote:
>>
could QTBUG-46143 possibly be added to the list of blockers? it is a P1
bug in qt3d/qt5.5, as it does not build against the macos10.
We are happy to share the results of our work on cross-platform high-DPI
scaling in Qt, which is planned for Qt 5.6. It is now at a stage where it can
be tested by others. You can get the code from our branch in qtbase:
wip/highdpi. The branch is open for business, and contributions are welcome.
> On 11 May 2015, at 23:12, m...@rpzdesign.com wrote:
>
> Thiago:
>
> My intention was never (explicity or implied) to insult anyone.
>
> Now I know who the platform maintainer is!
>
> https://wiki.qt.io/Maintainers
>
> And how Mr Sorvig could take offense!
>
> And for that I share my sincer
> On 11 May 2015, at 08:45, Ziller Eike wrote:
>
>>
>> On May 10, 2015, at 9:08 PM, mark diener wrote:
>>
>> Well, it looks like the big weakness in OSX deployment is macdeployqt and we
>> are on version 5.4.1+
>>
>> I was able to change my macdeployqt command line FROM:
>>
>> macdeployqt
> On 17 Apr 2015, at 10:48, Allan Sandfeld Jensen wrote:
>
>
> Ideally the orientation could also be kept as metadata in QImage.
I’d like to see general metadata support in QImage. The closest thing we have
seems to be QImage::text(), which supports QString data only.
My specific use case se
> On 27 Feb 2015, at 14:34, Blasche Alexander
> wrote:
>
> If 10.7 is required then it should be added back to main CI targets. If it is
> not added back then I will remove consequently remove every trace of it.
I don’t think it will be added back. You should remove it from your branch as
wel
> On 24 Feb 2015, at 07:24, Jeremy Whiting wrote:
>
> Hello list,
>
> I discussed a bit with Thiago and some others on irc this evening and have
> realized that the QStandardPaths patch from [1] and discussion on [2] is
> trying to solve too many problems at once. I'll list the problems here
> On 23 Feb 2015, at 13:00, Knoll Lars wrote:
>
>
> Yes, I still don’t like the fact we’re embedding a 1.7M xml file in Qt
> Core at all. I’m not too fond of checking the binary file into the
> repositories, but it’s probably still better than continuing with the XML
> file.
For OS X I’d like
> On 22 Feb 2015, at 18:50, Jeremy Lainé wrote:
>
> On 02/22/2015 06:42 PM, Richard Moore wrote:
>>
>>
>> On 22 February 2015 at 17:39, Jeremy Lainé wrote:
>>
>> Whilst I agree with the goal of dropping support for old / unmaintained
>> OpenSSL versions, in the case of OS X we probably need
> On 18 Feb 2015, at 10:59, Robert Iakobashvili wrote:
>
> What about support for @3x?
> Is it inside or is it planned?
I’ve started implementing @3x support here:
https://codereview.qt-project.org/106717
https://codereview.qt-project.org/106705
There’s some refactoring work to be done as wel
> On 06 Feb 2015, at 09:32, Ziller Eike wrote:
>
>>
>> What simpler alternative do you have in mind?
>
> One possibility that would cover the use case of “show some simple styled
> html without javascript” case (e.g. documentation browsers) would be to give
> QTextBrowser some love again, fi
> On 02 Feb 2015, at 10:01, Sarajärvi Tony
> wrote:
>
> Hi
>
> Here's a wiki page describing the planned changed along with a bit of version
> information of the tools:
>
> http://qt-project.org/wiki/Qt-5.5.0-tools-and-versions
>
Since OS X 10.7 is no longer CI tested that makes the status
> On 26 Jan 2015, at 09:09, Robert Iakobashvili wrote:
>
> It seems that QStyle returns 0.
>
> Should I create some style in advance and pass it to application?
> Which style could be appropriate for 10.6?
>
> Yes, I know that 10.6 is not a supported target for 5.4.0,
> but any advise or direc
> On 22 Jan 2015, at 07:52, Blasche Alexander
> wrote:
>
> Hi,
>
> I'd like to nominate Timur Pocheptsov for approver status. He wrote the OSX
> and iOS implementations for QtBluetooth and lately has been increasing his
> footprint in other modules for the same platforms.
>
> https://codere
> On 24 Dec 2014, at 14:48, Александр Волков wrote:
>
> Hi all,
>
> Currently three major platform plugins (xcb, windows and cocoa) by default
> behave
> absolutely different when they receive synthesized mouse events from the
> system:
> 3) cocoa plugin doesn't distinguish them from real mo
> On 24 Sep 2014, at 16:17, Alexander Ilyin
> wrote:
>
> CODESIGN FAILED WITH MESSAGE "unsealed contents present in the root
> directory of an embedded framework In subcomponent:
> /Developer/res-plan/bin/s-test.app/Contents/Frameworks/QtCore.framework"
> (Please look at the listing below)
>
>
> On 22 Sep 2014, at 12:03, Sorvig Morten wrote:
>
>
>> On 19 Sep 2014, at 11:28, Sorvig Morten wrote:
>>
>> This will indeed receive attention in the coming days. There are already
>> some patches attached to the QTBUGs. I’ll post back here once we ha
> On 19 Sep 2014, at 11:28, Sorvig Morten wrote:
>
> This will indeed receive attention in the coming days. There are already some
> patches attached to the QTBUGs. I’ll post back here once we have a complete
> patch set ready. Target branches are Qt 5.3 and Qt 4.8.
I’m using
>
> And the Info.plist should *always* set CFBundleExecutable to QtCore. To use
> the debug version you set the DYLD_IMAGE_SUFFIX environment variable to
> _debug prior to execution.
A minor case: What would you do for debug-only builds?
>
> As far as I'm aware, we already do this correctly (
> On 18 Sep 2014, at 22:07, Adam Strzelecki wrote:
>
>> Reported already 24/Jan/14 QTBUG-36429
>
> FYI more recent and prioritized bug report is QTBUG-38511
>
> I think it deserves a lot of attention now since 10.9.5 is live.
This will indeed receive attention in the coming days. There are al
> On 27 Aug 2014, at 22:02, Milian Wolff wrote:
>
>
> A synchronous API is bound to fail, see WK1 vs. WK2/WebEngine. Make it
> asynchronous and copy the WebEngine API.
I see now QQuickWebEngineView has:
runJavaScript(const QString &script, const QJSValue &callback)
So that settles th
> On 27 Aug 2014, at 16:51, Milian Wolff wrote:
>
> On Wednesday 27 August 2014 14:49:08 Hausmann Simon wrote:
>> I'm pretty sure that all the "native" webview APIs allow for at least
>> runJavascript(string), so injection may also be an easier option.
>
> Oh nice, I assumed without testing nor
> On 12 Aug 2014, at 16:25, Adam Strzelecki wrote:
>
> Okay, Phase II.
>
> (1) Introduce "bundle_frameworks" CONFIG option, and set it default for
> "rpath" shared builds on iOS & OS X
>
> (2) Introduce "bundle" make target, when "bundle_frameworks" CONFIG is set,
> it is added to "all"
>
>
> On 12 Aug 2014, at 13:37, Adam Strzelecki wrote:
>
>> On to my now standard question: Can you summarize the discussion so far into
>> a proposal on what you want to change? Keep it as short as possible :) For
>> example, I think it’s understood that (incremental) framework coping is fast
>>
> On 11 Aug 2014, at 23:15, Jake Petroules wrote:
>
> This was mostly a counterargument to people complaining against copying
> frameworks into the bundle. However, copying frameworks into the bundle is
> the correct solution, and is what must be done in the end.
>
> It'll be nice when qbs so
On 04 Aug 2014, at 21:38, Adam Strzelecki wrote:
>> Before you do that, can you write up a proposal on what you want to
>> accomplish and how to get there?
>
> WHAT I WANT TO ACCOMPLISH
>
> (1) Remove need to rewrite Qt libraries (frameworks) headers during install
> and during macdeployqt
>
On 04 Aug 2014, at 12:22, Adam Strzelecki wrote:
>> So, let's end this discussion and start focusing efforts towards building
>> the solution.
>
>
> Now let's focus on submitting patches :>
Before you do that, can you write up a proposal on what you want to accomplish
and how to get there? T
On 03 Jul 2014, at 17:13, Sune Vuorela wrote:
> On 2014-07-03, Milian Wolff wrote:
>> I imagine, it could work by create just a normal library but not install and
>> public headers, only private ones. That should be OK then, or what do you
>> think?
>
> We have too many private headers alrea
A quick report from the contributors summit (I apologize for the delay and
sketchy notes):
* I went though the general approach:
- Setting the scale factor:
- platform plugin: QWindow::devicePixelRatio, QScreen::devicePixelRatio
- the user: QT_HIGHDPI_SCALE_FACTOR=2
- per
On 11 Jun 2014, at 14:53, Thiago Macieira wrote:
> Em ter 10 jun 2014, às 21:33:44, Daiwei Li escreveu:
>> Hello,
>>
>> I'm investigating porting an existing C++/QML application to Google
>> NaCl, and I found that Qt had attempted a port a couple years ago:
>> http://qt-project.org/wiki/Qt_for_
On 05 Jun 2014, at 00:25, Thiago Macieira wrote:
> Em qua 04 jun 2014, às 10:32:17, Olivier Goffart escreveu:
>> In general, i think it would be beneficial to have some public API in
>> QObject to create dynamic signals or slots.
>
> This has been asked from the QML-on-Go discussions. We just
On 27 May 2014, at 18:36, Daiwei Li wrote:
>
> BTW, any idea when your platform independent high DPI changes will
> make it in (or be in a working state in the review)? I would love to
> try having Android scale using the platform independent code.
The patches are now in a working state. New ch
On 27 May 2014, at 11:47, Daiwei Li wrote:
> Hi Morten,
>
> My understanding of your platform independent change was that it would let
> the scale factor be set by the user at runtime with an environment variable.
> Is it meant to replace all platform plugin scaling (I.e. iOS and OSX) or
> au
On 26 May 2014, at 22:40, Daiwei Li wrote:
> I took a stab at adding high DPI support to Android and created a review
> here: https://codereview.qt-project.org/#change,86260. I would appreciate any
> feedback (e.g. what tests need to be added, what other corner cases need to
> scaled, etc...)
On 26 May 2014, at 07:59, Ziller Eike wrote:
>
> On May 23, 2014, at 6:03 PM, m...@rpzdesign.com wrote:
>
>> Sorvig:
>>
>>> From the latest new front:
>>
>> http://bgr.com/2014/03/18/nexus-9-specs-details/
>>
>> Digitimes on Tuesday cited its own research arm in reporting that Google
>> wil
On 23 May 2014, at 18:30, Thiago Macieira wrote:
> Em sex 23 maio 2014, às 07:20:42, Sorvig Morten escreveu:
>> Adding support to QtWayland looks like a win to me. Do we want to add
>> platform-indepent support to Qt?
>
> I think my question is: why wouldn't we?
The
Over the past year-and-a-half we’ve implemented high-dpi scaling for Qt on Mac
OS X and iOS. Now we have an excellent opportunity to bring this support to
other platforms.
A quick recap for those unfamiliar: This high-dpi mode is an alternative to the
traditional DPI scaling. In the traditiona
On 11 May 2014, at 21:53, Tim Blechmann wrote:
>
> the 32bit versions seem to use the _debug suffix ... the difference does
> not occur in all frameworks, but only in:
> QtCore.framework
> QtMultimediaQuick_p.framework
> QtPrintSupport.framework
> QtScriptTools.framework
> QtSerialPort.framewor
On 29 Apr 2014, at 13:31, Richard Moore wrote:
>
> I actually started thinking about how a smaller API for some of this could
> look. Basically with the idea being that for many applications only a subset
> of the full QSslXX apis mattered. If you want me to post my notes (such as
> they are)
On 29 Apr 2014, at 14:21, Jeremy Lainé wrote:
> On 04/29/2014 01:13 PM, Sorvig Morten wrote:
>> QSSLSocket/QSslCertificate/QSslCipher is a relatively large API - make sure
>> you are aware of the scope of the project and remember you have to maintain
>> it :)
>
On 29 Apr 2014, at 00:39, Thiago Macieira wrote:
> Em ter 29 abr 2014, às 00:16:43, Jeremy Lainé escreveu:
>> On 04/28/2014 11:44 AM, Nichols Andy wrote:
>>> It is possible still in the packaged versions of Qt for iOS to make
>>> connections using SSL via QNetworkAccessManager as there is a back
+1 from me as well.
In addition to his submissions Jake is knowledgeable about all things Mac and
has provided solid advice on several occasions.
Morten
On 16 Apr 2014, at 09:08, Christian Kandeler
wrote:
> On 04/15/2014 07:13 PM, Thiago Macieira wrote:
>> I'd like to nominate Jake Petroules
On 22 Apr 2014, at 12:49, Simon Hausmann wrote:
> On Monday 21. April 2014 15.13.08 Robert Knight wrote:
>>> The design direction is because QML is easier to develop with, more
>>> modern,
>>> and based on OpenGL. Widgets don't have that and will never be as
>>> efficient.>
>>> Therefore, the e
On 24 Mar 2014, at 16:37, Derek Cole wrote:
> Well the original intention was to use the Qt network module. I have not
> attempted to re-write to use OpenSSL directly.
If your use of QtNetwork is limited to QNetworkAccessManager get/post/put then
you don't have to ship OpenSSL. Qt on iOS wil
Will this patch work?
https://codereview.qt-project.org/#change,80620
Morten
On 11 Mar 2014, at 12:12, Kurt Pattyn wrote:
> Some more information.
>
> I work on OSX.
> When digging into the platform specific implementation, I detected that in
> the method qcgl_createNSOpenGLPixelFormat()
>
On 30 Jan 2014, at 01:15, John Layt wrote:
>
> I've just pushed a 33 commit change set for this to Gerrit, my apologies to
> the people I've tagged as reviewers :-) Any one else interested, feel free
> to
> jump in and help.
>
> There's 4 main new classes:
> * QPageSize
> * QPageMargins
> *
On 21 Jan 2014, at 13:20, Tor Arne Vestbø wrote:
>
>
> On 21/01/14 11:23 , Sorvig Morten wrote:
>> I agree with many of these arguments, and I was in favor of setting
>> the minimum supported version to 10.7 back when we started Qt 5
>> development. But we did m
On 20 Jan 2014, at 21:21, deDietrich Gabriel
wrote:
> The truth is, market share doesn’t mean anything. Point in case: According to
> the link above, OS X is less than 8% of the total market share. Should we
> then drop the Mac port completely?
Good question! Possible arguments for not discont
On 21 Jan 2014, at 11:51, Simon Hausmann wrote:
> On Tuesday 21. January 2014 10.23.22 Sorvig Morten wrote:
>> On 21 Jan 2014, at 09:32, Simon Hausmann wrote:
>>> On Monday 20. January 2014 20.21.14 deDietrich Gabriel wrote:
>>>> On Jan 20, 2014, at 7:55 PM, A
On 21 Jan 2014, at 09:32, Simon Hausmann wrote:
> On Monday 20. January 2014 20.21.14 deDietrich Gabriel wrote:
>> On Jan 20, 2014, at 7:55 PM, Allan Sandfeld Jensen wrote:
>>> On Monday 20 January 2014, Thiago Macieira wrote:
On segunda-feira, 20 de janeiro de 2014 17:36:26, Kurt Pattyn w
On 18 Dec 2013, at 01:22, Thiago Macieira wrote:
>
> If it turns out that the failure to destroy is harmless, I'm not sure we
> should do anything. If it's harmless, that means the extra work required to
> free the memory is wasted, since it has no benefit to anyone. Just wasted CPU
> cycles.
+1 from me as well.
Morten
On 17 Dec 2013, at 12:42, Knoll Lars wrote:
> Hi,
>
> I’d like to nominate Paul Tvete as the formal maintainer of the QPA
> architecture. He’s the original architect behind it anyway, and I don’t
> think there are many people out there who know it better :)
>
> Chee
On 04 Dec 2013, at 11:47, Sletta Gunnar wrote:
> QWidget has the exact opposite problem. Layouts, styles and rendering happens
> in pixel units while fonts are sized in point size. This is also a problem
> when moving between platfoms as the pixelsize of a point has a different
> definition o
On 27 Nov 2013, at 16:24, Ziller Eike wrote:
>
>>> Adding plugins into the respective frameworks would simplify deployment
>>> significantly. macdeployqt's task would be reduced to inspecting the
>>> frameworks the app links against, and copying the framework folders into
>>> the bundle. Don't
On 27 Nov 2013, at 12:06, Adam Strzelecki wrote:
>
> I am hereby submitting my candidature. I am registered Mac&iOS developer. I
> am personally interested to improve Qt experience on Mac, since I am using it
> for several projects. I may either submit patches or fork Git master.
>
> Of course
On 15 Nov 2013, at 09:37, Martin Smith wrote:
>
> On Nov 15, 2013, at 9:32 AM, Sorvig Morten
> wrote:
>>
>> (and someone needs to port tools/qdoc/qmlparser)
>
> I just did that a couple weeks ago. Has there been a more recent update?
No, it’s ok. I was looking at
On 14 Nov 2013, at 09:39, Stephen Kelly wrote:
>
> Hello,
>
> I get build errors when trying to build qtbase dev branch for raspbian.
> /home/stephen/dev/src/qtbase/src/tools/qdoc/qmlvisitor.cpp:51:0:
> /home/stephen/dev/src/qtbase/src/tools/qdoc/qmlvisitor.h:78:29: error:
> ‘QQmlJS::AST::Ui
On 05 Nov 2013, at 19:17, Shaw Andy wrote:
> IIRC it wasn’t even compiled into the QtWidgets library, although the
> documentation and everything existed, those symbols were never in Qt. Morten
> can say 100% at least but that is my understanding and recollection at least.
That is correct, th
On 06 Nov 2013, at 17:18, Kai-Uwe Behrmann wrote:
> What is the point of special casing sRGB?
sRGB is special for a couple of reasons:
- Most/Many of the images published for web are in the sRGB color space.
- OpenGL has support for sRGB textures and frame buffers.
Given that progress has halte
On 15 Oct 2013, at 13:54, Eduardo Montesinos wrote:
> Hi everybody,
> Then I run qmake and open the generated xcodeproj in XCode, build and run in
> simulator. The app starts up, but clicking on the TextInput field does no
> effect, no keyboard on screen shows up. The lines
> • testInput
On 04 Nov 2013, at 10:49, John Layt wrote:
> On 4 November 2013 08:22, Sletta Gunnar wrote:
>> The work that was done is here:
>> https://codereview.qt-project.org/#dashboard,1002033
>>
>> The work was abandoned after the transition to Digia and the author is no
>> longer in the Qt community
On 05 Nov 2013, at 17:01, Matt Broadstone wrote:
>
> Cool,
> I've been in touch with the macports patch author and he submitted a number
> of his patches this morning for review. I'm sure they overlap, but perhaps
> there are changes there that could help as well (I haven't reviewed any of
>
On 02 Nov 2013, at 17:58, Thiago Macieira wrote:
> On quarta-feira, 30 de outubro de 2013 07:29:56, Turunen Tuukka wrote:
>> We should have the applications made with Qt 4.8.5 on Mac OS 10.7 (for
>> example) working in 10.9 without serious issues. And we should be able to
>> agree together what i
I’d like to second (third?) going for approach 1.
It’s possible that we would want to implement secure socket support for
QWebSocket using native API instead of QTcpSocket
and OpenSSL at some point. We are currently doing this for
QNetworkAccessManager on OS X and iOS
(https://codereview.qt-pro
On Oct 3, 2013, at 2:30 PM, Jørgen Lind wrote:
>>
>
> But if you happen to have pkg-config in your path, why should we then
> not use it. The user has "one way or the other" added it to the path,
> so why shouldn't it be used.
>
> I think the interesting question is why configure fails when yo
On Oct 3, 2013, at 3:10 AM, Glen Mabey
wrote:
>
> I'm on the dev branch but experienced this issue before the 5.2 and 5.3
> branches split.
>
> macbookpro:qtbase$ ./configure -prefix ~/src/take2/install
>
>
>
> Running configuration tests...
> The test for linking against libxcb and suppor
dereview.qt-project.org/#change,64803.
>
> --
> J-P Nurmi
>
> On Sep 4, 2013, at 2:35 PM, Tor Arne Vestbø wrote:
>
>> Yes yes a thousand times yes!
>>
>> On 9/3/13 14:41 , Sorvig Morten wrote:
>>> I think the advantages of having these functions
the functionality was already in Qt 4 and was moved out for Qt 5
> because of maintenance issues and different code for different platforms
> exposed to the customer.
>
> On 02/09/2013 10:35 PM, Sorvig Morten wrote:
>> I agree the "Extra" looks superfluous. In fact I
I agree the "Extra" looks superfluous. In fact I'd like to go a bit further and
suggest we don't have platform extras at all and instead integrate the
functionality into Qt:
- Conversion functions for types in QtCore to QtCore
- Conversion functions for types in QtGui to QtGui
- Widgets to QtWid
These kinds of errors can usually be diagnosed by increasing the output
verbosity a bit. Try running "macdeployqt myapp.app -verbose=2". Where does the
reference to QtScript come from?
Morten
On Aug 25, 2013, at 10:45 AM, qtnext wrote:
> is there any chance that maceployqt will be fixed for
On Aug 23, 2013, at 10:32 AM, Olivier Goffart
wrote:
>>
>> https://codereview.qt-project.org/#change,62948
>> is linked to a bug without categorization
This one went to stable because
- crash/infinite loop fix
- trivial patch for a corner case
- fix for new functionality.
I don't think we've
1 - 100 of 172 matches
Mail list logo
