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
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
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 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 could be
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
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 Dijon
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
___
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
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
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 property
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 you
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 case
On Sun, Apr 27, 2014 at 10:37 PM, Thiago Macieira
thiago.macie...@intel.com 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
On 27 April 2014 22:31, Mark Gaiser mark...@gmail.com 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
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
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++ developers. If
On Mon, Apr 28, 2014 at 6:53 AM, Thiago Macieira
thiago.macie...@intel.comwrote:
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
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
pretty much
18 matches
Mail list logo
