Tab is likely being grabbed by the window itself (or maybe the
QKeySequenceEdit is ignoring) because it's using the tab as a switch to the
next thing in the tab order action.
On Fri, Jun 24, 2022 at 9:51 AM Laszlo Papp wrote:
> Hi,
>
> I am unable to assign tab to QKeySequenceEdit. Do you know w
to review patches in that direction though if you or someone else
has time to create them :)
BR,
Jeremy
On Fri, Sep 18, 2015 at 6:51 AM, Robert Iakobashvili
wrote:
> On Fri, Sep 18, 2015 at 3:48 PM, Robert Iakobashvili
> wrote:
>> On Fri, Sep 18, 2015 at 3:24 PM, Turunen Tuukka
I see the feature freeze is approaching quickly. Did the status of
QtSpeech getting into QT 5.6 ever get sorted out? Is there still some
work that needs to be done before this can happen? If so what needs to
be done?
BR,
Jeremy
On Thu, May 28, 2015 at 5:25 AM, Frederik Gladhorn
wrote:
> Th
hich does message-oriented
communications :)
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Samuel,
That looks good (from me, with not much Android experience), though
there are some things to improve that are already commented on that
review since April. Are you planning to fix those and update it?
BR,
Jeremy
On Mon, May 11, 2015 at 1:50 AM, Samuel Nevala
wrote:
> Hi,
>
that hasn't happened yet and ought to
get done before QtSpeech is added to 5.6.
thanks,
Jeremy
On Fri, May 8, 2015 at 7:48 AM, Frederik Gladhorn
wrote:
> On Friday, May 08, 2015 10:41:04 AM Lisandro Damián Nicanor Pérez Meyer wrote:
>> On Friday 08 May 2015 14:59:22 Frederik Gladhor
On 04/13/2015 03:46 PM, Nurmi J-P wrote:
> On 13 Apr 2015, at 14:50, Jeremy Lainé wrote:
>
>> How about just "android-controls", which would become
>> "qt-android-controls" if the project graduates from playground?
> I like this suggestion. In the en
the project graduates from playground?
Cheers,
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
I love it when I send a question to an e-mail list then find the answer
myself. My bad, the NSSpeechSynthesizer documentation at apple was wrong.
Filing a bug now.
BR,
Jeremy
On Mon, Mar 2, 2015 at 7:16 PM, Jeremy Whiting wrote:
> Hello,
>
> Inside QtSpeech in the mac backend we have
er
voice's attributes NSDictionary. The backtrace in lldb looks like this:
bowser:qtspeech jeremy$ lldb
examples/widgets/hello_speak/hello_speak.app/Contents/MacOS/hello_speak
(lldb) target create
"examples/widgets/hello_speak/hello_speak.app/Contents/MacOS/hello_speak"
Current ex
Tor Arne,
As a test I modified my setup on OS X yesterday to pass
-DCMAKE_INSTALL_DATADIR="/Users/jeremy/Library/Application Support/" to
every KDE module's cmake comand. This successfully installed all supporting
data files into ~/Library/Application Support/foo and only requi
possibly help make it easier to port applications and
libraries from one of Qt's platforms to another.
Thoughts, opinions, counterarguments, suggestions?
BR,
Jeremy
[1] https://codereview.qt-project.org/#/c/103277/
[2] https://bugreports.qt.io/browse/QTBUG-44473
__
/ ALPN.
>
>
> No idea on that one, but I'd imagine they'll want to support http/2 in
> safari at some point.
>
Well, the thing is that Safari already supports SPDY, but that did not
translate into any (public?) API for NPN in Secure Tranport...
Jeremy
_
On 02/22/2015 06:42 PM, Richard Moore wrote:
>
>
> On 22 February 2015 at 17:39, Jeremy Lainé <mailto:jeremy.la...@m4x.org>> wrote:
>
>
> Whilst I agree with the goal of dropping support for old /
> unmaintained
> OpenSSL versions, in the case of OS
for OpenSSL-based binaries. This means that a lot of
users will not be exposed to this new backend at all, and then suddenly
in Qt 5.6 the old backend will be completely gone, with no way to build
it even from source.
Cheers,
Jeremy
___
Development maili
On 02/06/2015 03:17 PM, Richard Moore wrote:
> The secure transport backend for Qt's SSL support was merged earlier
> this week [1] thanks to some great work by Jeremy Laine and Timur
> Pocheptsov. Please could those using Macos X and iOS give it a try and
> see how it works
+1
On Thu, Jan 29, 2015 at 3:24 PM, Robin Burchell
wrote:
> Hi,
>
> Rationale: Text.AutoFormat is a terrible misfeature in almost every
> case out there.
>
> Design implications: In many cases in applications, a format is not
> specified, with the assumption that only plain text will ever be
> d
ed by like this:
QMakeVar add DEFINES QT_NO_MTDEV
..which results in this -DQT_NO_MTDEV being passed directly to the compiler
(which works
for iOS too). Is this what I should be doing instead?
Thanks,
Jeremy
[1] https://codereview.qt-project.org/
On 5September2014, at 12:33, Tomaz Canabrava wrote:
> Long that that I have send this e-mail already, but better late than never.
> In the Qt Develompent Summit I raised my hand to get one dirty thing done:
>
> The Settings.
>
The general idea appeals to me.
> After a good while with nega
On 5September2014, at 21:57, Thiago Macieira wrote:
> On Thursday 18 September 2014 21:46:27 Jeremy wrote:
>> I don’t see an issue with removing it from Qt 5. Is there a general plan for
>> modules that exit from production-ready status?
>
> Modules that exit from product
On 5September2014, at 02:05, Joerg Bornemann wrote:
> The qtjsondb module is dead. It doesn't build since ages and has zero
> users. As civilized people we should bury our dead.
> Therefore I'd like to request the removal of qtjsondb from Qt's mother
> repository.
>
> Please raise any objecti
t
<http://qt-project.org/doc/qt-5/qtqml-javascript-qmlglobalobject.html#xmlhttprequest>
does
not enforce the same origin policy.
=> you don't care about cross origin requests, much less preflighting.
Jeremy
___
Development mailing list
De
heers,
Jeremy
On 05/30/2014 12:20 AM, Richard Moore wrote:
> What Jeremy has done here is fantastic. My estimate when I was
> previously asked how hard it was to write a new backend to the SSL
> support was approximately a man month given a developer who already
> knew the subject area. I&#
qssl-ios branch from
https://qt.gitorious.org/qt/sharkys-qtbase on a OS X machine
2/ Apply the attached patch to fix / disable some QSslSocket unit tests
3/ Build it
4/ Run some unit tests
5/ Help fix the errors :)
Cheers,
Jeremy
PS: no unfortunately I cannot make it to the contributor sum
ing as simple as High, Medium and Low! After all,
> most people (including developers) don't know the trade-offs of the
> different cipher suites anyway. We could also have a flag for perfect
> forward secrecy since that is independent of the strength. It would
> also be possible t
On 05/01/2014 03:51 PM, Jeremy Lainé wrote:
> One problem I am going to run into is that Apple's API doesn't seem to
> provide error
> details when a certificate check fails (SecTrustEvaluate), so I don't think
> we'll get as
> fine-grained QSslError'
ned QSslError's as when using OpenSSL. I have however managed to
implement the
pattern used in the OpenSSL implementation:
- start handshake
- emit sslErrors if appropriate
- allow ignoring the errors using ignoreSslErrors
- complete handshake
Cheers,
Jeremy
_
tbase.
Cheers,
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Reference/reference.html
For now I am implementing a rough proof of concept (attached) outside Qt
by subclassing QTcpSocket the way QSslSocket does .
Cheers,
Jeremy
#include
#include
class FooSocket : public QTcpSocket
{
Q_OBJECT
public:
FooSocket(QObject *parent = 0);
On 29 Apr 2014 00:39, Thiago Macieira wrote:
>
> Em ter 29 abr 2014, às 00:16:43, Jeremy Lainé escreveu:
> > What would the best course of action be to add support for secure
> > websockets
> > on iOS?
>
> Probably to add a new QSslSocket backend that uses t
Qt that use OpenSSL directly (like QSSLSocket).
Ouch I just realised that most likely means QWebSocket on iOS does not support
secure
websockets!
What would the best course of action be to add support for secure websockets on
iOS?
Cheers,
Jeremy
___
On 11/04/2013 05:13 PM, Robert Knight wrote:
> Thanks for your work on QtNetwork Shane!
>
Same here, thanks a lot Shane for your work and for your patience getting
QDnsLookup into
shape!
Jeremy
___
Development mailing list
Development@qt-proje
i. This
will come up again, and it's unreasonable to expect someone to find,
read, and understand the conclusion of a mailing list discussion when a
few sentences in a central location will suffice.
The wiki could probably use some house keeping.
Jeremy
___
This doesn't mean that you can't change a score after being convinced by
another review.
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
will be that the user wants
to load
such or such .qm file depending on the current locale. Unfortunately I don't
think QLocale
is accessible from QML. Would a constant "localeName" property make sense in
TranslationLoader?
Cheers,
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Le Jul 31, 2012 à 9:34 AM, Alan Alpert a écrit :
> On Mon, 30 Jul 2012 19:34:23 ext Jeremy Lainé wrote:
>> I have found QML's network transparency very handy for loading whole UIs
>> over the network, it makes it possible for instance to have "live updates"
>>
the URL to the .qm file
- enumeration status (Null / Ready / Loading / Error): the loader's status
Any thoughts on such an addition, or on a better API?
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
BC promise for this case doesn't have much value.
Compatible patch level releases sound like a nice target if they don't
involve excessive pain.
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
> - finalise the class name (I think QDns was suggested)
>
Could we get this point settled once and for all? My suggestions:
- QDnsLookup (my preferred one, as the object represents a lookup and its
result)
- QDnsInfo (similar to QHostInfo)
- QDns
s then it makes sense to limit how many can be processed at once
> via a thread pool).
>
I followed QHostInfo's pattern exactly here: I set a fixed maximum number of
threads (5)
on the pool.
Jeremy
___
Development mailing list
Deve
then we need to be able to tell the user that the reply has already
> finished.
As you stated, the reply object lives in the calling thread, and the finished()
signal is
always emitted in a queued fashion, so I think we're OK.
Jeremy
___
De
ss
for incrementally parsing HTTP requests or responses (with or without the
initial line).
The use case I have is a Qt-based HTTP-server, but there are probably others..
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
style)
- the thread and the QDnsReply both operate on a
QSharedPointer, so it doesn't matter whether the QDnsReply is
deleted before or after the thread completes
Cheers,
Jeremy
___
Development mailing list
Development@qt-project.org
http://lis
(n9 top posting sorry)
+1 for me, it's hard enough making sense of phonon vs qtmultimedia. Also from a
naming point of view QSound is far too generic.
Jeremy
On 24/11/2011 12:23 Thiago Macieira wrote:
An idea to consider.
I don't think *anyone* uses QSound these days.
--
Thiag
On 11/09/2011 07:41 PM, Giuseppe D'Angelo wrote:
> On 9 November 2011 18:35, Jeremy Lainé wrote:
>> C/ you make QDnsReply's constructor public, and let the user manage the
>> lifetime of the
>> object. This is what the Q3Dns API looks like. What I don't like a
On 11/09/2011 07:21 PM, Peter Hartmann wrote:
> On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
>> (...)
>> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>>
>> pro: easy to connect to the QDnsReply's signal
>> con: it's entirely up
On 11/09/2011 06:21 PM, Robin Burchell wrote:
> On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé wrote:
>> This talk about QtConcurrent has me wondering: do we need an asynchronous
>> API at all?
> I really dislike synchronous APIs, even more so when they're the only
> opti
the DNS API is not dependent on QtConcurrent, but using them together is
straightforward
Any thoughts?
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Le Nov 9, 2011 à 10:14 AM, André Somers a écrit :
>
>
> On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to
On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
>> - the QNAM-style API seems to be OK
> Correct, but all functions in QDnsResolver are static.
>
> That means they could go into QDnsReply and we could rename the c
,
it has the
advantage of being well-known
Unless there are any objections I will push the reworked QDnsResolver to gerrit.
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On 11/04/2011 09:01 PM, Andre Somers wrote:
> Op 4-11-2011 20:31, Jeremy Lainé schreef:
>> On 11/04/2011 10:15 AM, André Somers wrote:
>>> The more I think about it, the more I think it is important to fix this:
>>> who is
>>> responsible for the lifetime of
on the record type:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682082%28v=vs.85%29.aspx
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
nstead of
> as a pointer. It would be nice we could come up with a single approach for
> these kinds
> of things and use that all over the place...
I brought this up with Thiago on IRC, as I quite like the idea of using a
QFuture. Ho
t; if need be.
>
> There's no way to provide the unsupported formats in QString. It would need
> to
> be QByteArray and, even then, it's useless if it contains a compressed domain
> name.
>
Domain name expansion is handled for known fields, win32
t; The problem is the DNS reply. Each query type contains a different kind of
>> data
>> structure that would need to be parsed. It gets very complex very quickly if
>> we want to present the data in a nice, C++ class.
>
> I am wondering: According to Jeremy it would be bes
ote: I can't guarantee the win32 code still compiles, there might be some
minor tweaks due to code refactoring.
Comments are most welcome!
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html
>
Same here, I think the low-level API needs to exist, but I am not opposed to
building some
convenience logic on top of it.
Jeremy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
ation, like "A")
> To avoid ambiguity with other types of service, QDnsService makes sense to me.
>
Ah, excellent, the names have been bothering me ever since I started writing
these classes. Does anyone see a problem with QDnsServiceInfo /
for
review [4]. Comments are welcome!
Jeremy
[1] https://bugreports.qt.nokia.com/browse/QTBUG-10481
[2] http://code.google.com/p/qxmpp/
[3] http://qt.gitorious.org/qt/qt/merge_requests/887
[4] http://codereview.qt-project.org/7475
___
Development
Not sure if it is of interest if your focus is on fcgi but I have a qt-based
http server I'd be happy to contribute:
http://opensource.bolloretelecom.eu/projects/qdjango/browser/src/QDjangoHttpServer.h
Am at qtdd11 if you want to talk.
--
Jeremy
On 25/10/11 04:38 Dhaivat Pandya wrote:
61 matches
Mail list logo
