> QtWebEngine and Chromium in the Qt 5.6 branch have been patched to
> allow linking with system libraries on Linux instead of bundled libraries.
What upstream changes have the Chromium team made to the bundled libraries
compared to the system ones and are Chromium upstream supportive of taking
pa
Follow-up question - if a data type is a union of a pointer and some
other representation, can it be stored in a QVariant without
transitioning to the allocated version?
On 3 August 2015 at 03:39, Thiago Macieira wrote:
> On Monday 03 August 2015 03:23:44 Mark Langezaal wrote:
>> On 2015-08-01 23
> What I mean is that you'll incur a heap allocation when doing
> ...
> I don't think there is and there has never been any inline method in QDateTime
> that dereferences the d pointer, so using a nullptr to indicate shared null is
> acceptable.
Hmm, perhaps QDT could avoid a heap allocation entir
> What is sorely needed is a fast, prototyping-friendly and
> platform-agnostic way of doing UIs while relying on their native
> implementation of widgets, usage patterns, libraries etc.
Xamarin and React Native are aiming to get as close to that as
feasible without compromising
on design - which
> I'd like to request a playground repository for the former hackathon project
> of mine: QML bindings for native Android controls -
> https://youtu.be/Mo8J-g5XPGQ
This looks great and IMO the only way to be sure of being able to
create a top-tier UX for Android or iOS for an app that is intend
a web server) and for that domain, distro policies
around bundling make a lot of sense.
On Fri Feb 06 2015 at 18:45:27 Matthew Woehlke <
mw_tr...@users.sourceforge.net> wrote:
> On 2015-02-06 09:22, Robert Knight wrote:
> >> It is just not practical to ship a second copy of d
> It is just not practical to ship a second copy of dozens
> of system libraries, all built as part of QtWebEngine. This is a nightmare
> in terms of disk space, RAM use, potential for symbol conflicts and
delivery
> of security updates.
These are all valid concerns but ultimately of secondary imp
> There are 109 commits since Qt 4.8.6 and you can find changes in this
snapshot from
> 4.8.7-snapshot-2014-12-22-1-changes –file (git log output) next to the
installers
Where is this file? I couldn't see it in
http://download.qt.io/snapshots/qt/4.8/4.8.7/2014-12-22-1/
On 22 December 2014 at 12:5
eys();
>
>
> Output:
>
> "Me C"
>
> "Me B"
>
> "Me F"
>
> Keys: ("C", "B", "F")
>
>
> Bug report here -> https://bugreports.qt-project.org/browse/QTBUG-42507
>
>
>
> On
> Consider the following program, shouldn't the end() iterator place each
key at the end of the newly created QMap. Instead, the keys and subsequent
iterations are sorted (somehow).
Yes, that's the whole point of a QMap. If you don't care about the order of
elements in a map, you should almost alw
Hi Alexander,
See the 'fixup_framework_bundle' function in
https://github.com/Mendeley/Mac-OS-X-Bundle-Utilities/blob/master/hdiutil-codesign.rb
for code which can fix a Qt bundle.
In short:
- There should be no files in the root of the
'Qt.framework' directory other than a 'Versions'
directory,
For anyone who is using CMake to build DMG packages using Qt, we have
a script to fix up the layout of Qt repos prior to building at
https://github.com/Mendeley/Mac-OS-X-Bundle-Utilities
This was targeted at Qt 4 but the Qt 5 bundles have the same structure
and issues as far as I see.
On 19 Septe
> Bot classes do NOT allow any default conversions (neither bool nor
> value nor string) which made their usage a bit more verbose but
> improved readability and safety a lot.
My experience has been similar. I took the std::optional proposal as a
starting point and stripped it back to just the bas
I've written a basic Option class with a minimal interface to
address the problems with bool* OK args Julien mentioned and found it
useful - both
in terms of communicating that something may not have a value and also
it avoids the need for an invalid/null/empty version of T to be
defined.
*However
As I understand it, the only reason for a major version bump from Qt 5
-> 6 is for backwards-incompatible changes, not new features.
> recall that the C++ Standards committee is looking at speculative work to
> support "modules"
Any modules implementation is going to have to have an associated
m
Hi Stephen,
Thanks for all your contributions over the years. Up to anything
interesting next?
On 16 July 2014 14:25, Stephen Kelly wrote:
>
> Hi,
>
> After 5 years, my time at KDAB is coming to an end, and I'm going to have less
> time for Qt development. I'll still be available for reviews.
>
I would recommend using CMake - it has a stable Ninja generator, which
_does_ make building Qt projects much faster on Windows.
On 19 May 2014 09:57, Oswald Buddenhagen wrote:
> On Sun, May 18, 2014 at 05:29:56PM +0200, Adam Strzelecki wrote:
>> Hello,
>>
>> I wonder if there was any work done in
sed?
Regards,
Rob.
On 7 May 2014 10:37, Mikołaj Siedlarek wrote:
> On 07 May 2014, at 11:15, Robert Knight wrote:
>>> It is a very good idea to have the Qt files treated as system files.
>>> I’ve gone to great lengths to filter out the warnings from Qt in our CMake
>>
> It is a very good idea to have the Qt files treated as system files.
> I’ve gone to great lengths to filter out the warnings from Qt in our CMake
> files
I would caution against that. Could we just fix the warnings in Qt
headers instead?
I enabled suppression of warnings in Qt headers for a pr
> After playing a bit with Xamarin (yes, I know, but put aside the C# hate for
> a minute),
> it's quite striking what different approaches can result in (and it also made
> it quite clear what Qt is doing better - but also worse than other cross
> platform solutions).
Have you elaborated on t
> Unfortunately that means there are now 4 completely separate UI stacks
> to maintain in Qt - widgets,
> QGraphicsView, the web and QtQuick v2. I wonder if they could be
> harmonized at all?
>
> We can use QML to describe UIs in all four.
True - but I'm thinking more about the implementation. If
> 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 effort is directed towards the technology that has the
> potential
> to make interfaces for 2017-2020.
Unfortunately that
This is UI toolkit plus windowing abstraction layer as I understand it.
Converting Chrome terminology to Qt:
'Views' => Qt widgets (QPushButton etc.)
'Aura' => The foundations of QWidget (event routing, alien widgets,
the backing store, QPlatform* classes)
'Ash' => A window manager. The front-end
> On Windows some older hardware and driver combinations
> do not provide a sufficiently well working OpenGL implementation yet they
> do have a working DirectX implementation which ANGLE then wraps to
> provide an OpenGL ES 2 implementation
Do you have any idea of numbers or how old "old" is? Wha
> Unfortunately, it looks to me that time based releases seem to
> encourage developers to try to rush to get their feature in.
The theory is that developers shouldn't panic about missing a
particular release because the next release date is predictable
and developers can catch the next train if n
> Has anyone managed to create an ActiveQt server with CMake?
To clarify, is the problem with running the IDC/IDL tools or some
other step? The CMake logic we've used for this is roughly:
set(IDL_COMMANDS
COMMAND idl ${BINARY_PATH} -idl ${BINARY_PATH}.idl
COMMAND midl ${BINARY_PATH}.idl ${BIN
> Sadly there is no easy migration path and this implies a full rewrite.
Do you have a writeup of the options you looked at and results of each one?
QtQuick might be the best way forwards but a full rewrite is usually
something to be very wary
of unless the requirements for the product itself hav
> Returning default-constructed value is heavily used practice in qt api and it
> simplifies our code.
It is often convenient, but he problem is that an error can propagate
a long way from the source before it gets discovered, which makes
debugging difficult, especially if the error gets propagat
> The idea was to silently return a default-constructed type.
I'm not keen on that. Aside from adding extra restrictions to the
types that the class can be used with as you mention,
it runs the much more severe risk of masking serious bugs.
Regard,
Rob.
On 4 February 2014 23:12, Matthew Woehlke
> I'll write QOptional tomorrow or on Wednesday, after I've had the chance
> to read the proposal to C++14 (that was dropped).
What would the plan for handling value access on unset options be?
std::optional<>
throws an exception. I initially did the same when implementing an
Optional class
but ra
That was the implicit assumption in my comment but I'm not in a
position to comment on whether that is accurate or not.
Regards,
Rob.
On 27 January 2014 09:08, Ziller Eike wrote:
>
> On Jan 26, 2014, at 8:10 PM, Robert Knight wrote:
>
>>> In regards to users of Mac OS Qt appli
> In regards to users of Mac OS Qt applications: I’m am extremely confident
> that more Mac OS applications would be/have been written in Qt,
> if the priority for native looking widget support was higher. Mac OS users
> are notorious for their attention to detail and noticing a non-native L&F.
>
> If you do the math from the data available here
> http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0
> (that’s December 2013), 10.6 accounts for slightly less than 20% of all the
> OS X versions. Let’s suppose those numbers reflect the reality.
For our app at
> That’s correct. In Qt Creator master branch (i.e. 3.1 series) you can choose
> the code model of different languages to use clang as a code model backend
What are the pros/cons of the two options for C++ as it currently stands?
Regards,
Rob.
On 23 January 2014 07:55, Ziller Eike wrote:
>
> O
Hello,
> I don't know about the codebase, but given the feedback for Qt Creator there
> are still a lot of people using XP even as a development platform ...
> so I'd expect quite some backslash if we completely drop support for Windows
> XP, at least for 'traditional' QWidget based apps.
I'm a
> yes, this was a conscious decision. Does it create usability issues for you?
Digia is trying to sell a UI toolkit for native app development.
Surely you want one of Qt's flagship apps to create a good first
impression!
On 2 December 2013 16:32, Giuseppe D'Angelo wrote:
> On 2 December 2013 16:
> Just use this where you need native looking text:
Having to put that everywhere a Text {} element is used in a
cross-platform app is ugly. One could wrap this in a custom component
but it shouldn't be necessary for such a basic use case.
Regards,
Rob.
On 2 December 2013 11:11, Ziller Eike wro
> As many of you might already have noticed, OpenGL drivers are not always
> working as well as would like.
To what extent does this apply to different platforms and vendors? Is
Qt doing anything different from other GL apps on the same platform or
are they facing the same issues?
On 29 November
Thanks for your work on QtNetwork Shane!
On 4 November 2013 12:31, Richard Moore wrote:
> Hi All,
>
> As some of you may know, Shane has a new job and therefore has a lot
> less time to spend on QtNetwork. He, Peter and I have discussed how we
> should maintain the module in the future. What we'r
> I noticed the post is 5+ years old, has it been tested
> on (modern) Fedora and does it still work with modern versions of Kubuntu?
I haven't tested it myself recently and I have no idea whether it
works with current versions of Ubuntu or whether
it ever worked on Fedora.
Regards,
Rob.
On 31 O
There is already a caching mechanism in place for the Compose file,
can we make use of that? -
http://kdemonkey.blogspot.co.uk/2008/04/magic-trick.html
On 31 October 2013 07:38, Knoll Lars wrote:
> Before going to a binary format, I’d first like to check whether we can
> further speed up the pars
> But seriously - how about pre-compiled headers? Is anyone using this compiler
> feature? Does it really help?
Yes and yes. There is a huge amount of redundancy in compilation of
typical C++ projects. YMMV but effective use of
precompiled headers can help significantly.
There are a couple of ru
> The time has come to focus on UI details, and this is where Qt gives me grey
> hairs. I started out developing in Qt 4.8, and experienced several issues
> that didn’t work on the Mac (From the top of my head: Overlays on video
> widgets), or just looked plain wrong in
> Mac OS context (For exam
> However, std::function and std::bind were already in tr1,
> which AFAIK is already supported by all the compiler we support (Tier1 +
Tier2)
> (MSVC 2008 and gcc 4.2 have it)
For VC 2008 it is part of an add-on pack [1], but it is available.
> We could have something like QObject <- QFutureBase
file
operations, parsing. QFuture provides a cancel() method and a QThread's
event loop can be quit between processing events but these only work
between task execution.
Regards,
Rob.
On 20 February 2013 16:24, Robert Knight wrote:
> Hello,
>
> A few thoughts:
>
> - In g
Hello,
A few thoughts:
- In general and especially for newcomers, encourage task-orientated
concurrency and avoiding shared state where possible.
This partly about documentation and the examples but also in the kind of
approach that the APIs optimize for.
- Having had the er, pleasure of debuggi
> If added to Qt, we would consider dropping our in-house implementations
to use Glen's QNDArray (this is serious investigation at present).
What stops you or anyone else from using QNDArray if it is maintained
outside of Qt?
Regards,
Rob.
On 9 January 2013 13:50, Charley Bay wrote:
> If add
> All modeless dialogs disappear behind the main application whenever
> the user clicks outside them (consider a Find/Replace dialog which
> always needs to be on top of the main application window).
Set the window type to Qt::Tool in the QDialog or QWidget constructor on
Mac, which corresponds to
> The main reason for committing this now is to close the feature regression
> from Qt 4 to Qt 5.
> Qt 4 gets high-dpi support via the CoreGraphics paint engine. Qt 5 uses
> raster and we need to do the implementation work in Qt.
Have you measured at all how performance compares between Qt 4 and
> I wonder if your guys could modify the QNetworkAccessManager's method
> declaration(get, post, put...), make them be virtual,
> so that I can derive a subclass and modify the implementation
You can already do this. Re-implement the protected createRequest() method.
Regards,
Rob.
On 3 Novembe
> However, I've recently decided to follow a different path and I will no
> longer be able to maintain the text editors and C++ language support.
Thanks for all your work. The C++ language/API assistance
implementation in Qt Creator is great to work with.
Regards,
Rob.
On 20 September 2012 22
> It's intended for when the source code of the implementation isn't available
> so internal variables and function names can be completely hidden.
That is not the motivation at all in Qt's case. The reasons for it are:
- Binary compatibility between minor Qt versions. Adding, removing or
cha
> it takes 100% CPU when the game is sitting idle.
What does the poor man's profiler* say is going on?
Regards,
Rob.
* http://poormansprofiler.org/
On 31 August 2012 19:26, Jeff Tranter wrote:
> I see the same thing with the Qt 5 beta 1 installer binary on Ubuntu
> Linux 12.04. When running
>
> This can be either quick-n-dirty
> passing a concatenated string (semicolon separated or whatever) as the path
> value, or getting fancy with passing pointers to structures that may have
> several pieces of info packed in
I'd just add an extra parameter to the signal which is empty for some even
> Notice how on Mac we get notified on the exact leaf-most folder where the
> event
> happened, and that the event is always just "something changed here".
Are you sure about that? The documentation specifies an
kFSEventStreamEventFlagMustScanSubDirs flag for
events which indicates that a proble
> With FSEvents you cannot emit signals such as fileChanged(), fileModified(),
> pathCreated(), or pathDeleted() if all you're notified about is that
> "something happened in this folder here",
>From my experience building an app that 'watches' a folder and imports
all files of a certain type
adde
56 matches
Mail list logo
