On 28.04.2014 08:10, Kurt Pattyn wrote:
>
>
>> On 28 Apr 2014, at 07:53, Peter Kümmel wrote:
>>
>>> On 27.04.2014 22:40, Thiago Macieira wrote:
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
> On 26.04.2014 17:39, André Pönitz wrote:
> You could have made the point "declarati
Hi,
I have installed qt-opensource-mac-x64-ios-5.3.0-beta.dmg
and while compiling my app, I get:
no member named 'sslConfiguration' in 'QNetworkReply'
which is happening when QT_NO_SSL is defined - which seems to be the case
in qconfig.h:
#if defined(QT_NO_OPENSSL) && defined(QT_OPENSSL)
# undef Q
> On 28 Apr 2014, at 07:53, Peter Kümmel wrote:
>
>> On 27.04.2014 22:40, Thiago Macieira wrote:
>>> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
On 26.04.2014 17:39, André Pönitz wrote:
You could have made the point "declarative structures are good for GUI
description
On 28.04.2014 00:55, André Pönitz wrote:
> On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
>> Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
>>> Having imperative code on the JS side is also the root of the rejection of
>>> QML for many C++ developers. If QML would have be
On 27.04.2014 22:41, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
>> Then adding 100MB just to run QML really hurts, and you start
>> looking for alternatives, like using only QWidgets with very
>> limited OpenGL support or not to use a Qt-GUI at all.
>
> Of thos
On 27.04.2014 22:40, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
>> On 26.04.2014 17:39, André Pönitz wrote:
>>> You could have made the point "declarative structures are good for GUI
>>> description" for Qt Widget's .ui files, after all, .ui files contents
>>>
On Mon, Apr 28, 2014 at 6:53 AM, Thiago Macieira
wrote:
> Em dom 27 abr 2014 15:01:10 você escreveu:
> > > It's not the only available choice. Widgets are available. They just
> look
> > > horrible because no one has done any work to make them look native.
> >
> > Is my understating correct that:
Em seg 28 abr 2014, às 00:55:12, André Pönitz escreveu:
> On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
> > Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
> > > Having imperative code on the JS side is also the root of the rejection
> > > of
> > > QML for many C++ develo
On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
> Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
> > Having imperative code on the JS side is also the root of the rejection of
> > QML for many C++ developers. If QML would have been just a improved .ui
> > nobody would have
On 27 April 2014 22:31, Mark Gaiser wrote:
> Actually, you can..
> http://css-tricks.com/a-couple-of-use-cases-for-calc/
>
> And even Internet Explorer has support for it:
> http://caniuse.com/#feat=calc
>
>
It's a variant of the expression() facility that IE has offered to CSS
since IE6. It's ex
On Sun, Apr 27, 2014 at 10:37 PM, Thiago Macieira
wrote:
> Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
>> Having imperative code on the JS side is also the root of the rejection of
>> QML for many C++ developers. If QML would have been just a improved .ui
>> nobody would have complaine
Em dom 27 abr 2014, às 11:08:44, Denis Shienkov escreveu:
> Here I am a little disagree. Because in Unbuffered mode, loss of data is
> exists. For example, in a case when the port accepts a data stream. And
> when the user ignores readyRead() signal, i.e do not reads nothing from
> port. In this ca
Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
> Having imperative code on the JS side is also the root of the rejection of
> QML for many C++ developers. If QML would have been just a improved .ui
> nobody would have complained.
We'd end up with one of the problems of CSS which is that y
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
> On 26.04.2014 17:39, André Pönitz wrote:
> > You could have made the point "declarative structures are good for GUI
> > description" for Qt Widget's .ui files, after all, .ui files contents
> > pretty much _is_ declaring layout nesting and p
Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu:
> Then adding 100MB just to run QML really hurts, and you start
> looking for alternatives, like using only QWidgets with very
> limited OpenGL support or not to use a Qt-GUI at all.
Of those 100 MB, 30 MB are taken by QtCore and QtGui (inclu
Hmm, but why don't you use Qml like that then? The language doesn't force you
to use inline js code, does it?
A lot of the work that has gone into the engine lately also enables this to
work better and reduce the use of JS. For example bindings that just consist of
a qsTr don't actually end up
On Sunday 27 April 2014 12:55:58 Peter Kümmel wrote:
> Having imperative code on the JS side is also the root of the rejection of
> QML for many C++ developers. If QML would have been just a improved .ui
> nobody would have complained.
+1
Frank
___
Deve
On 27/04/2014 12:55, Peter Kümmel wrote:
> Having imperative code on the JS side is also the root of the rejection of QML
> for many C++ developers. If QML would have been just a improved .ui nobody
> would
> have complained.
+1
--
(o< | Yves Bailly | -o)
//\ | Linux D
On 21.04.2014 13:39, Roland Winklmeier wrote:
> - Memory consumption: Even a mini example took about 70 MB of memory,
> QtWidgets need a lot less. This is not a complain, I know the JS runtime
> needs its initial memory. It was just one factor, because our
> application is running as an addon to Fl
On 26.04.2014 17:39, André Pönitz wrote:
>
> You could have made the point "declarative structures are good for GUI
> description" for Qt Widget's .ui files, after all, .ui files contents
> pretty much _is_ declaring layout nesting and property values.
Just an idea:
Declarative-only QML files coul
On 25.04.2014 12:18, Joerg Bornemann wrote:
>
> Yep, I hear people keep repeating the mantra "QML is declarative. It's
> just QML/JS that isn't."
I think the "declarative-mantra" is a good idea, especially when used for
_specifying_ (not programming) the GUI.
At Adobe they tried it with pure C++
On 24.04.2014 21:15, Attila Csipa wrote:
> solutions to cross platform mobile development :( 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 be
Hi Carlos.
> Look at the read/write calls in Unix. If you use the asynchronous
mode of operation you will get an error if the data cannot be
read/written. No data is lost, unless you explicitly delete the data you
pass to those functions. And from your point of view there is no way to
tell if
23 matches
Mail list logo
