Hi all,
We have new RC snapshot available in
http://download.qt-project.org/snapshots/qt/5.3/5.3.0-RC/2014-04-21_65/
Mirroring is ongoing but all installers should be available later today. Please
test these & verify your fixes!
Qt5 changes in these packages:
https://codereview.qt-project.org/#c
On 4/21/2014 3:46 PM, Marius Storm-Olsen wrote:
> I would like to request your participation in a survey on
> Open Source Organizational Culture,
> which will provide valuable insight into how Open Source projects are
> run, how their participants act, how they might change going forward,
> an
Hi,
I would like to request your participation in a survey on
Open Source Organizational Culture,
which will provide valuable insight into how Open Source projects are run, how
their participants act, how they might change going forward, and how particular
Open Source projects compare with
I have been reading the discussions about Qt’s future and strongly feel that
it's full of promise. Last year I used a different application framework but
the company went bankrupt without notifying its users. I then tried several
other frameworks but wasn’t happy with any of them. Then I came ac
Em seg 21 abr 2014, às 14:21:24, Kuba Ober escreveu:
> Essentially, there’s only *two* changes I’d like to see in QSerialPort’s
> implementation. These changes may not be possible to implement on all
> platforms, of course. The `QSerialPort` API must be nonblocking, that’s the
> whole point of havi
Essentially, there’s only *two* changes I’d like to see in QSerialPort’s
implementation. These changes may not be possible to implement on all
platforms, of course. The `QSerialPort` API must be nonblocking, that’s the
whole point of having it to start with. Doing blocking reads/writes is trivia
I'm not Roland (talking about "value-types"), but I completely agree with
his comments on why they are important (we have that issue also).
But, "jumping-in", ...
,
> >> - Our application has a huge framework of value classes. They cannot
> (or
> > >> at least it does not make sense to) derive f
On Monday, 2014-04-21, 14:15:16, André Pönitz wrote:
> On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote:
> > The language "barrier" between C++ and QML makes it easier to see where UI
> > ends and program logic begins, leading to better abstraction between core
> > application and its
Thiago:
I really appreciate your and Intel's participation in the open source Qt
project.
I think you misunderstood what I was talking about and forcefully
rejected that which I did not ask.
I want the "pattern" brought forward, but we should not try to bring the
code forward. Let sleeping dogs
On Monday, 2014-04-21, 14:52:25, Roland Winklmeier wrote:
> >> - Our application has a huge framework of value classes. They cannot (or
> >> at least it does not make sense to) derive from QObject for several
> >> reasons. But subclassing QObject is the requirement to access data from
> >> C++ in Q
On Monday, 2014-04-21, 10:59:43, m...@rpzdesign.com wrote:
> You can separate the GUI from the Model in C++ Classes as well, not just
> in QML/js vs C++ boundary.
Of course. I meant that the boundary makes it more obvious when you are
attemping logic within the UI since you very explicitly switc
On Monday, 2014-04-21, 15:13:08, Robert Knight wrote:
> > The design direction is because QML is easier to develop with, more
> > modern,
> > and based on OpenGL. Widgets don't have that and will never be as
> > efficient.>
> > Therefore, the effort is directed towards the technology that has the
Thiago,
many thanks for your help.
BR,
Denis
21.04.2014 20:12, Thiago Macieira пишет:
> Em seg 21 abr 2014, às 16:50:50, Denis Shienkov escreveu:
>> Hmmm..
>>
>> Thiago, what do you mean by "writeable"? It is when device was opened in
>> the WriteOnly (ReadWrite) mode, or something else?
> When
Em seg 21 abr 2014, às 10:59:43, m...@rpzdesign.com escreveu:
> Can Qt Widgets design pattern be brought forward using the same OpenGL
> foundation
> that QML uses to instantiate controls?
Short answer: no.
Long answer: if you want it working in other platforms, without glitches and
regressions
Em seg 21 abr 2014, às 15:31:57, Yves Bailly escreveu:
> QML has its merit, it's certainly perfect for some projects. But for all
> I've seen and tried until now, only for projects having a rather simple UI.
> For really complex UIs, QML seems not suitable - at least for now.
So our effort goes in
Em seg 21 abr 2014, às 16:50:50, Denis Shienkov escreveu:
> Hmmm..
>
> Thiago, what do you mean by "writeable"? It is when device was opened in
> the WriteOnly (ReadWrite) mode, or something else?
When the underlying device can receive more bytes from the userspace.
Sockets and pipes are buffere
> So we started to design our UI
> with QML. I liked the design to split business logic into
> C++ and UI design into QML and I still like it, but I came across
> several blocking issues (some of them are only valid for our application, some
> of them are general):
>
> - Our application has a huge
Yves & Devs:
I take a different view of tablets. There MANY use cases where tablets
will do a HUGE amount of mission critical *REAL* work
and they will NOT use a keyboard or type 100 words a minute.
But I agree, we need both 100% C++ Qt Widget Option (not using .ui
files) AND QML/js (the new .
On Apr 21, 2014, at 6:31 AM, Yves Bailly wrote:
> On 21/04/2014 04:53, Thiago Macieira wrote:
>> Em dom 20 abr 2014, às 22:37:11, m...@rpzdesign.com escreveu:
>>> Isn't Qt Widgets so mature that they are stable?
>>
>> They are.
>
> But so much could still be done... as a basic example I stumbl
> The design direction is because QML is easier to develop with, more modern,
> and based on OpenGL. Widgets don't have that and will never be as efficient.
> Therefore, the effort is directed towards the technology that has the
> potential
> to make interfaces for 2017-2020.
Unfortunately that
On 21/04/2014 04:53, Thiago Macieira wrote:
> Em dom 20 abr 2014, às 22:37:11, m...@rpzdesign.com escreveu:
>> Isn't Qt Widgets so mature that they are stable?
>
> They are.
But so much could still be done... as a basic example I stumbled upon
very recently, why is it so hard to change the font of
Roland sayeth:
> , I liked the design to split business logic into
> C++ and UI design into QML and I still like it, but I came across
> several blocking issues (some of them are only valid for our
> application, some of them are general):
>
> - Our application has a huge framework of value classe
>>
>> - Our application has a huge framework of value classes. They cannot (or
>> at least it does not make sense to) derive from QObject for several
>> reasons. But subclassing QObject is the requirement to access data from
>> C++ in QML. So we had our framework of well designed value classes and
Hmmm..
Thiago, what do you mean by "writeable"? It is when device was opened in
the WriteOnly (ReadWrite) mode, or something else?
If I correctly understand, then I assume that the device always is
"writeable": i.e. opened in WriteOnly (ReadWrite) and the internal buffer
of writing is not empty.
On Apr 21, 2014, at 4:39 AM, Roland Winklmeier
wrote:
> Am 21.04.2014 05:27, schrieb Joshua Kolden:
>> I’m curious why you are not interested in QML.
>>
>> I’m just finishing up a an initial production release of software oriented
>> towards high-performance graphics. We used QML for the i
On Mon, Apr 21, 2014 at 10:53:01AM +0200, Kevin Krammer wrote:
> The language "barrier" between C++ and QML makes it easier to see where UI
> ends and program logic begins, leading to better abstraction between core
> application and its interface.
The compulsory QML/JS - C++ language cut genera
Am 21.04.2014 05:27, schrieb Joshua Kolden:
> I’m curious why you are not interested in QML.
>
> I’m just finishing up a an initial production release of software oriented
> towards high-performance graphics. We used QML for the interface,
> coffeescript for view logic, and Qt/c++ for process
Hi Michael,
In response to your email I have two questions:
1) As your email is addressed to the open source community working on Qt
itself, who are you referring to with "they"?
2) You are saying that you "want to be sure". What kind of assurance are you
looking for?
Simon
Opprinnelig me
On Monday, 2014-04-21, 01:40:50, Michael Knight wrote:
> I feel like Qt is going in the direction of being Qml and Javascript only.I
> fear that they may abandon Qt Widgets in the near future,I think they are
> heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I
> want to be
On Monday 21 April 2014 05:27:33 Joshua Kolden wrote:
> I’m curious why you are not interested in QML.
> [...]
> I see no reason to stay with Qt Widgets at all other than legacy
> application support. So what is your concern?
> [...]
Not speaking for Michael, but let me add that C++ is much easie
30 matches
Mail list logo
