Nice work!
I suppose you just want to replace the private implementation of QSSLSocket
leaving the QSSLSocket header intact?
QWebSockets depends further on the OpenSSL macro (can't remember the exact name
now) to decide whether SSL sockets are supported. I think we also need another
macro that
Hi all,
We have Qt5.3 RC candidate packages available in
http://download.qt-project.org/snapshots/qt/5.3/5.3.0-RC/2014-04-29_79/
Couple of windows packages are still missing but those will be available later
today.
These will be official Qt5.3 RC packages if nothing serious found during
testin
On 29 Apr 2014, at 7:51 PM, Alan Alpert wrote:
>> (3) Document that accessing ids from other .qml files without any interface
>> (just relying on the fact that they are in the context) creates hard to
>> maintain QML code.
>
> Agreed (honestly, it should already be there, I guess
> https://bug
Maybe writing an OpenSSL compatibility layer over Apple's API is also an option?
Does anyone has an idea where OpenSSL is used in Qt? Definitely for SSL
sockets, but maybe also for generating ciphers, hashes, aso?
Cheers,
Kurt
> On 29 Apr 2014, at 14:21, Jeremy Lainé wrote:
>
>> On 04/29/2014
> On 29 Apr 2014, at 13:31, Richard Moore wrote:
>
>
>
>
>> On 29 April 2014 12:13, Sorvig Morten wrote:
>> >> 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 the Apple API.
>>
>>
Hi Qt developers,
I migrated qtpanel from Qt4 to Qt5
but setAttribute(Qt::WA_X11NetWmWindowTypeDock, true) has NO effect for
Qt5 https://github.com/xiangzhai/qtpanel/blob/master/panelwindow.cpp#L138
qtpanel-qt4 snapshot
https://www.dropbox.com/s/nwebtd03fy4sght/qtpanel-qt4.png
BUT qtpanel-qt5 ht
I get strange scrolling behavior with QML's GridView on OSX with with a
touchpad doing the typical two finger scrolling gesture. Click drag seems to
be doing what two finger click drag should be. Is this a bug or am I missing a
step?
Also I have a large data base (orm) of image assets that I
Thiago, thank you very much for these explanations. About that option, it only
works on Windows so it's no good either way.
About generating wrappers for inlines, if you know of a tool that can do that -
as I mentioned earlier - it would be of great help to me.
On Tuesday, April 29, 2014 10:33
Em ter 29 abr 2014, às 08:06:37, Thiago Macieira escreveu:
> Em ter 29 abr 2014, às 04:45:37, Dimitar Dobrev escreveu:
> > Allan, I'm not talking about a custom build at all. This whole discussion
> > I
> > started is about how to avoid one. The results you see I've obtained from
> > the Qt 5.2.1 M
Em ter 29 abr 2014 08:08:35 você escreveu:
> Thiago,
>
> Thanks for that piece. I am not that familiar with such details of C++ so
> could you please explain why the function is public but compiled with
> hidden symbols?
[with permission to reply to the list]
There are two things here at stake:
I actually use https://github.com/mono/CppSharp . It has a parser and so on but
what I was asking for is a tool for generating wrappers. What I've been doing
so far is: get each inlined function -> get where it's invoked -> include the
header of the latter in a source file -> compile that with
On Tue, Apr 29, 2014 at 12:43 AM, Hartmann Thomas
wrote:
> Hi,
>
> On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz wrote:
>> I think at least three modifications are inavoidable: For one, things that
>> could be written in a declarative way but which currently are only possible
>> using JavaScript,
On Tue, Apr 29, 2014 at 07:43:09AM +, Hartmann Thomas wrote:
> > I think at least three modifications are inavoidable: For one, things that
> > could be written in a declarative way but which currently are only possible
> > using JavaScript, a declarative way should be added. Second, it should
Em ter 29 abr 2014, às 09:10:39, Dimitar Dobrev escreveu:
> Sharing with other bindings - now that's a great idea! I hadn't actually
> thought of the fact that such a wrapper is the same for any binding. If
> that could become a Qt module as you suggest, and presented as a binary
> download at qt-p
On 04/29/2014 02:39 PM, Sorvig Morten wrote:
> This aproach looks promising. If we can get basic QSslSocket working (enough
> for say QNAM and QWebSocket) then retiring the NSUrlConnection backend and
> focusing on QSslSocket is a possibility.
OK I have moved my proof of concept code here:
http
I'm not sure I understand your idea about compiling alongside. The binding is
C# so I'd have to either use C++/CLI or translate the body of the inline to C#
and compile that. The former works only for Windows, the latter is too much
work - essentially a C++ to C# converter. What is your suggesti
On Monday 28 April 2014 05:37:40 Dimitar Dobrev wrote:
> My problem (and, I'd say, any binding developer's) is
> that I can't tell users "my binding is great, you just need to compile Qt
> yourselves because the binary downloads don't work well enough" - nobody's
> going to use it.
But whoever is
Em ter 29 abr 2014, às 19:16:51, Denis Shienkov escreveu:
> > > Yes. Except that you're referring to non-existent unbuffered modes of
> > > QTcpSocket and QProcess...
> >
> > Ok, then what is it "This code is for the new Unbuffered QTcpSocket use
> > case"?
> >
> >
> > https://qt.gitorious.org/q
On 29 Apr 2014, at 3:34 PM, m...@rpzdesign.com wrote:
> Is there a class diagram on the current code base?
You can run doxygen on it and get the automatically-generated ones, but AFAIK
there has never been any emphasis on doing "internal" documentation, only
user-facing documentation. I don't
I understand. Thank you all for your time. Kai, I think you can close the issue
as "Won't Fix".
Regards,
Dimitar Dobrev
On Tuesday, April 29, 2014 6:24 PM, Thiago Macieira
wrote:
Em ter 29 abr 2014, às 04:45:37, Dimitar Dobrev escreveu:
> Allan, I'm not talking about a custom build at all.
Em ter 29 abr 2014, às 04:45:37, Dimitar Dobrev escreveu:
> Allan, I'm not talking about a custom build at all. This whole discussion I
> started is about how to avoid one. The results you see I've obtained from
> the Qt 5.2.1 MinGW binaries as downloaded from qt-project.org.
There won't be a chan
Em ter 29 abr 2014, às 13:43:00, Allan Sandfeld Jensen escreveu:
> On Tuesday 29 April 2014, Dimitar Dobrev wrote:
> > They are not emitted. I've opened QtCore with
> > http://www.dependencywalker.com/ and the only symbols I can see for
> > QModelIndex are:
> >
> > _ZNK11QModelIndex4dataEi
> > _ZN
2014-04-29 19:13 GMT+04:00 Denis Shienkov :
> > Yes. Except that you're referring to non-existent unbuffered modes of
> > QTcpSocket and QProcess...
>
> Ok, then what is it "This code is for the new Unbuffered QTcpSocket use
> case"?
>
>
> https://qt.gitorious.org/qt/qtbase/source/eb211d74cc3dbf99
Em ter 29 abr 2014, às 01:30:24, Dimitar Dobrev escreveu:
> I don't need invisible inlines either but some of them - such as
> QModelIndex::row() - are visible. Is there any way to emit just the visible
> inlines?
Still hidden:
$ readelf -Ws --dyn-syms libQt5Core.so.5 | c++filt| grep QModelIn
Em ter 29 abr 2014, às 12:48:55, Denis Shienkov escreveu:
> This is expected behavior?
Yes. Except that you're referring to non-existent unbuffered modes of
QTcpSocket and QProcess...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Thomas & Tero:
There is no way that I can make it to the contributors summit, but
Thomas' message might be a important discussion pience when you arrive
in Berlin.
Related to points 5,6,7 of Thomas' message Below:
Is there a class diagram on the current code base?
This would help newbies when t
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 :)
>
> I definitely realise implemen
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 :)
I definitely realise implementing the whole of the API is a large task.
However, just g
Allan, I'm not talking about a custom build at all. This whole discussion I
started is about how to avoid one. The results you see I've obtained from the
Qt 5.2.1 MinGW binaries as downloaded from qt-project.org.
On Tuesday, April 29, 2014 2:43 PM, Allan Sandfeld Jensen
wrote:
On Tuesday 29
On Tuesday 29 April 2014, Dimitar Dobrev wrote:
> They are not emitted. I've opened QtCore with
> http://www.dependencywalker.com/ and the only symbols I can see for
> QModelIndex are:
>
> _ZNK11QModelIndex4dataEi
> _ZNK11QModelIndex5childEii
> _ZNK11QModelIndex5flagsEv
> _ZNK11QModelIndex6parentE
On 29 April 2014 12:13, Sorvig Morten wrote:
> >> 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 the Apple API.
>
> QSSLSocket/QSslCertificate/QSslCipher is a relatively large API - make
> sure
They are not emitted. I've opened QtCore with http://www.dependencywalker.com/
and the only symbols I can see for QModelIndex are:
_ZNK11QModelIndex4dataEi
_ZNK11QModelIndex5childEii
_ZNK11QModelIndex5flagsEv
_ZNK11QModelIndex6parentEv
_ZNK11QModelIndex7isValidEv
_ZNK11QModelIndex7siblingEii
_ZNK
On Tuesday 29 April 2014, Dimitar Dobrev wrote:
> I don't need invisible inlines either but some of them - such as
> QModelIndex::row() - are visible. Is there any way to emit just the
> visible inlines?
>
Shouldn't be needed they are emitted by default. Only static inlines are
omitted from t
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
Simon,
In the description of the issue in JIRA I've pointed out why I don't like the
solution with an additional C/C++ wrapper. In short, I would have to compile
and pack such a lib for each OS, and then my users would have to deploy that
different per OS lib.
I'm not sure I understand your an
On Tuesday 29. April 2014 01.30.24 Dimitar Dobrev wrote:
> I don't need invisible inlines either but some of them - such as
> QModelIndex::row() - are visible. Is there any way to emit just the visible
> inlines?
I think the pinvoke approach of creating bindings just won't work reliably
with
This bug still exists in
qt-opensource-mac-x64-android-ios-5.3.0-RC_2014-04-29_02-22-23-53.dmg. iOS
developing is blocked totally.
On Mon, Apr 28, 2014 at 10:20 PM, Yang Fan wrote:
> Yes, I see the JIRA status, but I tried
> qt-opensource-mac-x64-android-ios-5.3.0-RC_2014-04-27_10-54-10-50.dmg
>That is why I suggest that when in Unbuffered mode, write/read should
behave as their Unix counterparts in non blocking mode. If the data cannot
be written at once, then refuse to write it (or to read it).
So, means it is possible to divide on main moments for possible I/O
implementation for the
I don't need invisible inlines either but some of them - such as
QModelIndex::row() - are visible. Is there any way to emit just the visible
inlines?
Dimitar
On Monday, April 28, 2014 4:12 PM, Thiago Macieira
wrote:
Em seg 28 abr 2014, às 11:15:23, Koehne Kai escreveu:
> > -Ori
> -Original Message-
> [...]
> On to the topic: QML is what the QML parser accepts (that is, JSON like
> declarative syntax + JavaScript in certain places). No, there's no standard
> document for it (in case that's what you're after), but it has a well-defined
> grammar etc. Christian Kamm
Coming right after 1st May.
(or maybe even tomorrow, if I can squeeze my schedule)
I will keep the registration open, and we will make fast decisions on late
requests.
Tero
> -Original Message-
> From: development-bounces+tero.kojo=digia@qt-project.org
> [mailto:development-bounces+
Hi Thiago,
>No, it isn't. The socket notifier activates when there's buffer available
in the
>kernel, not that the buffer is empty. That means something got flushed,
but it
>does not indicate that everything did.
>
>I will ask very specifically: what ioctl or fcntl do you need to enable to
get
>th
Hi,
Il 29/04/2014 09:56, Kojo Tero ha scritto:
Hello,
This is a reminder for everyone who has contributed to Qt in the past
year to request an invite to the Qt Contributors’ Summit.
When will the invitations be sent? It's only ~40 days before the summit
and people would need to ask for leave
On Tuesday 29. April 2014 07.17.14 Koehne Kai wrote:
> > -Original Message-
> > From: development-bounces+kai.koehne=digia@qt-project.org
> > [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> > Behalf Of Andre Ponitz
> > Sent: Monday, April 28, 2014 11:34 PM
> > To:
On Apr 28, 2014, at 8:12 PM, Alan Alpert <4163654...@gmail.com> wrote:
> On Mon, Apr 28, 2014 at 7:36 AM, Sze Howe Koh wrote:
>> On 25 April 2014 18:18, Joerg Bornemann wrote:
>>> On 25-Apr-14 04:21, Sze Howe Koh wrote:
>>>
I consider QML and JavaScript to be different languages. JavaScri
Hello,
This is a reminder for everyone who has contributed to Qt in the past year to
request an invite to the Qt Contributors' Summit.
The event will be in Berlin, June 10-11th. It's a meeting for Qt contributors
and developers. A time to look at where the project is and plan ahead for the
fut
On 04/28/2014 10:51 PM, André Pönitz wrote:
> I am tempted to suggest to reload http://www.classnamer.com/ until it
> contains Q, M, and L.
Don't waste your time. I've checked the source code and found that the
first word will never start with a 'Q'. Maybe we should fork it?
Christian
Hi,
On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz wrote:
> I think at least three modifications are inavoidable: For one, things that
> could be written in a declarative way but which currently are only possible
> using JavaScript, a declarative way should be added. Second, it should be
> stresse
> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> Behalf Of Andre Ponitz
> Sent: Monday, April 28, 2014 11:34 PM
> To: Alan Alpert
> Cc: development@qt-project.org
> Subject: Re: [De
50 matches
Mail list logo
