Hi,
On 05/01/2024 08:21, Elias Steurer via Development wrote:
> git for windows comes with perl
Is this new? Because my installation does not have it. I just checked,
and the folder my env path points to only contains git.exe,
git-gui.exe, and no Perl.
This is not new - it has (to my know
Hi,
Oh, yes, that works too.
I originally just used the first working URL I could infer from the web
page. It would be really super if cgit could show a proper clone URL.
Konrad
On 27/03/2023 15:31, Jukka Jokiniva via Development wrote:
Hi,
Should the repository url be without the “
On 26/03/2023 23:05, Andrey Leman wrote:
Hi,
Yes, the server has been upgraded to new version. Could you please
test if it works as before now? e.g https://code.qt.io/cgit/...
Nope, still getting errors on fetch:
cd qt3d.git
git fetch --all --tags
Fetching origin
fatal: repository 'https
Hi,
On 26/03/2023 14:16, Christian Ehrlicher wrote:
today there was a thread on stackoverflow which mentions that the links
to the examples don't work anymore. The links in the docs (and also in
the source repo) are
https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/...
But it needs t
Hi Kai,
thanks for looking into this.
One more discovery: the Qt Account credentials are also stored with 0557
permissions - they really should be 0600 for the file and 0700 or 0755
for the directory. Credential storage permissions should always be
overridden anyway and not be left to some automa
Hi,
I thought what the heck, lets update the pre-compiled Qt components on
my computer. Apart from making me jump through the Qt Account hoop, I'm
not sure whether this is deliberate (nefariously or incompetently) or
just broken (please tell me it is a simple bug!):
OS: Linux, Debian (testing),
On 2020-02-03 15:04, Vitaly Fanaskov wrote:
We don't need this method at all if everything is implemented with using
smart pointers.
What about the case when I want to delete a Widget from my window
without closing the window?
I often use deleteLater() because it is much easier than remember
On 2020-01-29 17:02, Volker Hilsheimer wrote:
You obviously don’t trust that TQtC will treat the data the
online-installer either demands or requires with the appropriate
confidence. So, shouldn't you build Qt from sources? Your IP address
is PII, after all. Why did you trust that The Qt Compan
Hi,
On 2020-01-29 09:52, Cristián Maureira-Fredes wrote:
I understand the video is an exaggeration,
Is it? I found it was pretty much bang on. Even for Qt: I just counted -
it took me 5 clicks, most of them not very intuitive, to download the Qt
installer I currently need (Linux 32bit on a 6
Hi,
On 11/23/19 9:47 AM, André Pönitz wrote:
qsizetype QContainer::size()
int QContainer::count() const
Please no! This will forever flood the interest mail list with questions
about what the difference between the two methods is. It will also
introduce a lot of subtle little misbeh
Hi,
On 6/27/19 3:47 AM, Lars Knoll wrote:
>
> Yes, Webengine uses some memory. But is that really a problem on developer
> machines?
It is a problem, but IMHO not the main problem. The main problem is that
WebEngine is not available on all platforms that are supported (as a
development host) by
Hi,
On 6/25/19 9:59 PM, Tor Arne Vestbø wrote:
> On 25 Jun 2019, at 21:30, Konrad Rosenbaum wrote:
>> Pardon my lingo,
> You should be able to communicate your points without that kind of lingo. Try
> better.
>
>> It is documentation for developers for crying out loud! I
Hi,
...my 2 cents or so...
On 6/25/19 4:30 PM, Palaraja, Kavindra wrote:
> No, parity isn't Google's search box. There's already a search feature in
> Creator.
>
> No, not "The Qt Company is hiring" either.
>
> The idea is to have parity in the sense of 1:1 appearance of how the
> documentation
Hi,
On 6/24/19 2:43 PM, Simon Hausmann wrote:
> We've had this situation for a long time now and I think that we should
> finally move forward and give our users better quality at the expense of
> their disk space, memory consumption and download size.
...at the risk of making enemies: so the pl
On 6/17/19 5:09 PM, Thiago Macieira wrote:
That's assistant. But do we need a standalone qch viewer application?
Yes please. There is at least one user who loves Qt and dislikes
QtCreator. While it is possible to view Qt Help in a browser, it is more
comfortable to use Assistant with its spe
On Tue, January 30, 2018 00:18, Kevin Kofler wrote:
> I would on the contrary expect users to want new features sooner rather
> than
> later,
[...]
Please keep in mind that there are several classes of Qt users:
Mobile: moving fast and furious. Depend on novelty.
General Desktop: moving somewhat
On Mon, October 2, 2017 11:54, René J. V. Bertin wrote:
> Konrad Rosenbaum wrote:
>> Whenever a QueuedConnection triggers the sending object generates an
>> event
>> and delivers it to the event queue of the thread that owns the target
>> slot's
>
> So the s
Hi,
On Saturday 30 September 2017 16:24:57 René J. V. Bertin wrote:
> Konrad Rosenbaum wrote:
> > Apart from this I'd suspect you will still get the SEGV if you do not
> > block - even if the frequency changes.
>
> As in when emitting the signal too frequently from mu
On Saturday 30 September 2017 11:31:13 René J. V. Bertin wrote:
> Thiago Macieira wrote:
[about internal mutex]
> > You cannot, because neither the kqueue, inotify or poll backends do
> > that.
> > Those three have no mutexes at all. You have to block the event loop of
> > the thread they were crea
Hi,
On Fri, September 29, 2017 11:35, René J.V. Bertin wrote:
> I've been running into issues using adding and removing entries from QFSW
> in concurrent threads.
[cut]
> The QFSW documentation only mentions the class is reentrant. Is QFSW
> supposed to be thread-safe (at least at the class level)
[quite OT, but I'll pile on... - just for fun]
On Mon, March 27, 2017 17:43, Matthew Woehlke wrote:
> Iä, thät güst lûks wråŋ. Yf wi wÿr tu ëvÿr du süch thyŋz, ai
wûd müch
Let me propose the more "Jusfull" "Jäh" - which is somewhat easier to read.
> räthÿr swytch holsel tu ü kümplitli fünëtyk sp
On Thursday, March 23, 2017 10:36:06 Marc Mutz wrote:
> There're
> proposals floating around for years to make o.f() fall back to f(o) for std
> C++.
Those are a lot more pain than you'd think! This construct already exists in
C# (static extension classes/methods) and it is causing major headache
On Mon, March 20, 2017 15:19, Marc Mutz wrote:
> Well, seriously. My answer is the same: Time has only one direction. Qt
> source
> and binary compatibility only has one direction. If you want to use Qt in
> a
> way it was not intended to be used, then you need to pay the prize, and
> not
> ask the
Hi,
On Mon, March 20, 2017 08:20, Olivier Goffart wrote:
> On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote:
>> The name is necessary for compatiblity iwth other languages.
>
> Can you elaborate?
> In QtScript or QtQml, the name is only used for error message, or for
> compatibility be
Hi,
On Wed, March 8, 2017 21:23, Jake Petroules wrote:
> Personally, I also prefer a build process never touch the network, but the
> average developer isn't that picky and just wants to Get Things Done.
The average test engineer is that picky and even worse! A test engineer
expects to save a mi
Hi Thiago,
On Fri, January 27, 2017 04:49, Thiago Macieira wrote:
> If it is IPv4, the priority for your issue has just dropped to the floor.
> I
> won't debug IPv4 multicast on Windows, on principle.
> I will review IPv4 patches, but I will not lift a finger to test them.
I'm not sure whether t
Hi,
On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote:
> Currently, MinGW builds in Coin use -system-zlib configuration. It happens
> because MinGW is shipped with zlib headers and libz.a. However, linking zlib
> to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is
>
Hi,
On Wed, September 21, 2016 10:11, probono wrote:
> 2016-09-19 16:45 GMT+02:00 Louai Al-Khanji :
>> From a quick look it seems to be mostly well written. I do wonder
>> whether it might be better to use a tool other than ldd to find the
>> library dependencies. objdump -p provides the same info
Hi,
On Monday 18 July 2016 07:59:21 Jędrzej Nowacki wrote:
> On Saturday 16 of July 2016 13:56:00 Konrad Rosenbaum wrote:
> > I am currently interfacing two libraries that only have QVariant in
> > common, most of the (value) types getting exchanged are either Qt
> > co
Hi,
I am currently interfacing two libraries that only have QVariant in common,
most of the (value) types getting exchanged are either Qt containers or
Q_GADGETs.
I was relatively quick to realize that I needed the QMetaType and
QMetaObject of these objects, but it took me pretty long to find
On Friday 10 July 2015 17:01:04 Smith Martin wrote:
> And apparently QVector has the same API as QList now, so why don't we
> deprecate QList. Let it always create a QVector.
Do you mean deprecate for use inside Qt? Maybe in Qt 6 or 7.
In general? For user code as well? HELL NO! (sorry for the sh
On Thursday 11 June 2015 07:29:51 Smith Martin wrote:
> onError is immediately understood by all sentient beings in the universe.
So, apparently either Germans are not sentient or from outside this
universe. Might explain a lot about me...
At the very least I disagree with your use of "immediate
On Thursday 17 July 2014 21:31:31 André Pönitz wrote:
> PS: Random side-track question: How comparable are values of type 'int'
> and 'QUrl' if one applies 'common sense'? I even accept answer related
> to non-0 int values only.
The trouble with common sense is that it is not very common in any se
On Wednesday 16 July 2014 08:41:07 Poenitz Andre wrote:
> Olivier Goffart wrote:
> > It's always a dilemma. We have to look at how likely we are to break
> > applications and I don't think adding a conversion is likely to cause
> > breakages.
>
> Type safety is a safety net that catches errors ver
On Saturday 03 May 2014, Richard Moore wrote:
> Support for QNAM
>
>
> It's obvious that to be useful, a backend must allow QNAM to make SSL
> requests. It need not support the more advanced features such as
> client certs, custom CAs, custom cipher suites etc.
>
> In order to ha
On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote:
> On 11 Feb 2014, at 19:14, Thiago Macieira wrote:
> > Em ter 11 fev 2014, às 16:26:44, Tony Van Eerd escreveu:
> >> http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful
> >
> > No doubt. And we should have
Hi,
On Tuesday, Tuesday 11 February 2014 at 00:03, Kurt Pattyn wrote:
> On 10 Feb 2014, at 20:17, Thiago Macieira wrote:
> > Em seg 10 fev 2014, às 19:54:18, Kurt Pattyn escreveu:
> >> Well, this is what I propose: use a delegate class that handles the
> >> creation of a random 32-bit number. Thi
Hi,
I'll have to read and analyze this code in more detail to give you a qualified
opinion. I'll do this later...
On the surface it looks a bit complicated and I'm not entirely sure about the
seeding, but I'll have to study the API first to make sure.
On Sunday, Sunday 09 February 2014 at 22:4
Hi Richard,
On Wednesday, Wednesday 29 January 2014 at 21:25, Richard Moore wrote:
> Sorry but most of this is irrelevant to Qt. Qt applications and QML
> applications are not like Javascript in a browser - they're already
> trusted and not sandboxed at all.
I know a few Qt applications that matc
Hi,
On Wednesday, Wednesday 29 January 2014 at 11:02, Koehne Kai wrote:
> > -Original Message-
> > From: development-bounces+kai.koehne=digia@qt-project.org
> > [...]
> > Later on: when a plan has been found to expose the low-level OpenSSL API
> > to Qt this implementation could be cha
ufficed. On the part of the paper (link below) I guess it is
typical of cryptographers to use cryptographic tools to the exclusion of
simpler tools, on the part of the RFC authors ... I don't know...?
On Monday, Monday 27 January 2014 at 11:12, Konrad Rosenbaum wrote:
> On Sunday, Sunday 2
On Monday, Monday 27 January 2014 at 09:06, Knoll Lars wrote:
> >With my change as it is, you'd see:
> >Actual (s1): Thiago Jos\u00E9 Macieira / Lars Knoll
> >Expected (s2): Thiago Jose\u0301 Macieira \u2215 L\u0430rs Knoll
>
> I know that, but we’re usually not writing our auto tests to try and
On Sunday, Sunday 26 January 2014 at 23:46, Richard Moore wrote:
> The aim of the masking is to prevent request splitting and smuggling
> attacks when going through proxies. It prevents an application from
> being to trick proxies into beginning a new request that does
> something different to the
Hi,
[wow, I had a good laugh!]
On Sunday 26 January 2014, Kurt Pattyn wrote:
> On 26 Jan 2014, at 11:31, Konrad Rosenbaum wrote:
> > Depends. What is it used for? Is it just obfuscation or is it supposed
> > to be real security?
>
> Well, there are 2 places where random
On Sunday 26 January 2014, Kurt Pattyn wrote:
> On 17 Jan 2014, at 19:46, Frederik Gladhorn
wrote:
> > Just another remark which I'm not sure about:
> > In section 5.2 of rfc 6455 randomness is mentioned. I didn't read up on
> > the background but currently there is only a call to initialize qsra
On Friday 27 December 2013, Mandeep Sandhu wrote:
> Got it. If there's some content in the 'body' part of the response and
> it points to the same server which sent a redirect, then we could
> reuse the existing connection.
>
> Though it might be a rare case where the redirects will have a 'body'
On Tuesday 05 November 2013 06:48:11 Alan Alpert wrote:
> I'm surprised this works. There's implicit QObject parenting built
> into the language, for example:
> QtObject {
> id: foo
> property Widget bar: Widget{}
> }
>
> Will automatically make foo the qobject parent of bar.
Correct, t
Hi,
IANAL, or: this is the increasingly hypothetical mail thread in which two
blind men discuss whether black or red robes look better on judges. :-)
On Monday 04 November 2013 16:52:36 Oswald Buddenhagen wrote:
> well, he can sue us.
> and then we sue his arse off for frivolous complaining, and
On Monday 04 November 2013 11:46:35 Oswald Buddenhagen wrote:
> On Sun, Nov 03, 2013 at 06:49:17AM -0800, Thiago Macieira wrote:
> > We can't even click the link. If we read their patches, we can't write
> > the same later.
>
> that's nonsense. any simple patch is not subject to copyright (though
On Saturday 02 November 2013, Kevin Krammer wrote:
> The Qt4 code does not call setParent if the object is a widget and the
> parent is not, e.g. if the parent is a layout. Still seems to work quite
> well.
>
> Maybe it would still work if the Qt5 code did something like this:
>
> if (!o->isWidge
Hi,
On Saturday 02 November 2013, Kevin Krammer wrote:
> On Thursday, 2013-10-31, 20:17:43, Konrad Rosenbaum wrote:
> > I've got it running
> > for trivial QML files, however as soon as there are child widgets the
> > running program aborts.
> >
> > The
Hi,
I'm trying to port KDAB's DeclarativeWidgets[1] to Qt5. I've got it running
for trivial QML files, however as soon as there are child widgets the
running program aborts.
The abort is caused by QObject::setParent, which contains this little gem:
Q_ASSERT(!d->isWidget);
Apart from not under
Hi,
On Wednesday 30 October 2013 14:36:23 Charley Bay wrote:
> This is an outstanding (and thorough/exhaustive/detailed) post on this
> topic.
Thanks! I was aiming for thorogh...
> Where can we put this in the Qt Docs or "Guidance-Help" for future users,
> and future Qt-internals-implementors?
Hi,
On Wednesday 30 October 2013 00:58:05 Calogero Mauceri wrote:
> The Qt documentation states that QDir::currentPath() returns "The
> application working directory". Shouldn't the workind directory be
> initialized with the path the application was launched from? If that's
> not the case, which
On Sunday 29 September 2013 22:26:41 Olivier Goffart wrote:
> As we do not modify those files, but take them from upstream, having a
> README that say where the file are from is enough.
> I don't see why it should be part of the tarball. (and especially they
> should not be in the git repositories)
Hi,
On Monday 23 September 2013 09:45:51 Olivier Goffart wrote:
> On Sunday 22 September 2013 16:25:25 Thiago Macieira wrote:
> > Right now, we allow them and I don't like the idea of forbidding forward
> > declarations.
> >
> > Therefore, doing anything that breaks them is source-incompatible an
Hi,
On Tuesday 06 August 2013 17:10:31 Thiago Macieira wrote:
> On terça-feira, 6 de agosto de 2013 15:41:21, Konrad Rosenbaum wrote:
> > On Sunday 04 August 2013 18:51:10 Thiago Macieira wrote:
> > > On domingo, 4 de agosto de 2013 10:20:51, Dmitry Ashkadov wrote:
> > >
On Sunday 04 August 2013 18:51:10 Thiago Macieira wrote:
> On domingo, 4 de agosto de 2013 10:20:51, Dmitry Ashkadov wrote:
> > LDD finds library using RPATH first of all, so, for local installed Qt5
>
> That's why RPATH was deprecated and replaced with RUNPATH.
Stupid question: is there a reason
On Thursday 11 April 2013 13:02:07 Turunen Tuukka wrote:
> PS. Torrents are still under study. Most likely they can be quite easily
> enabled, we'll see in the near future. Personally I am non convinced of
> their benefits, but maybe that is just me ;)
The benefits of torrents are not visible if y
On Saturday 26 January 2013, Laszlo Papp wrote:
> On Fri, Jan 25, 2013 at 9:05 PM, Knoll Lars wrote:
> > And a question: There's no auto tests. I know that testing serial
> > ports
> > can't really be done in an automated fashion, but is there anything we
> > can do to cover the module?
> * The
Hi,
On Monday 15 October 2012 15:56:23 Bache-Wiig Jens wrote:
> The main focus of Qt on the desktop is to provide a native look and feel on
> all platforms. Until now, Qt has come bundled with a few extra styles that
> were not used intentionally anywhere. Historically plastique was designed
> to
On Friday 03 August 2012 15:42:49 marius.storm-ol...@nokia.com wrote:
> On 03/08/2012 07:49, ext Thiago Macieira wrote:
> > And operator== can't change incompatibly.
>
> Does this mean that we should have an
> bool QDateTime::isIdentical(const QDateTime &dt)
> function too (effectively an ope
On Thursday 02 August 2012 23:01:55 you wrote:
> On Thursday August 2 2012, Konrad Rosenbaum wrote:
> > On Thursday 02 August 2012, Thiago Macieira wrote:
> > > On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
> > > > Where is qHash(QDateTime)
On Thursday 02 August 2012, Thiago Macieira wrote:
> On quinta-feira, 2 de agosto de 2012 17.55.54, Konrad Rosenbaum wrote:
> > Where is qHash(QDateTime) defined? It doesn't seem to be where I
> > expected it (qhash.* or qdatetime.*).
>
> qdatetime.{h,cpp}
Ok, found
Hi,
On Thursday 02 August 2012 15:27:03 Thiago Macieira wrote:
> For example, in when I was just now adding it to qHash for QDateTime, I
> realised it does complex operations. Right now, none of those operations
> allocate memory, but it's actually very close to doing that. QDateTime has
> a d poi
On Wednesday 15 February 2012, Stephen Kelly wrote:
> On Wednesday, February 15, 2012 21:55:54 Konrad Rosenbaum wrote:
> > The
> >
> > calculation results are almost identical. Almost.
>
> Is that enough?
>
> John Layt mentioned the existence of such a ma
Hi,
On Wednesday 01 February 2012 01:59:49 Stephen Kelly wrote:
> On Tuesday, January 31, 2012 22:50:51 you wrote:
> > * I'd prefer if we don't have to ship the database. As noted it can
> > change easily
> > and a compiled in database would get out of sync.
Look for the system database - on syst
67 matches
Mail list logo
