Hello,
Also I am curious why object_with_source was never backported to Qt 4.8.x. It
exists in Qt5 branch since least few last Qt 4.8 minor releases and it brings
significant improvement separating build folder from source tree.
Would it be possible to port it back? AFAIK looking in Qmake code
On Thursday, November 14, 2013 08:49:04 Thiago Macieira wrote:
> First of all, you seem to be linking statically to glibc. Don't.
You seem to start with an assumption that I changed something. Don't.
This is using the mkspec for raspberry pi supplied with Qt. I changed nothing.
Thanks,
--
Step
On Thu, Nov 14, 2013 at 11:20 AM, Topi Mäenpää wrote:
>> Pick the wrong interface classes, like QtScript did, and you suffer in
>> the long term. That's why we aren't committing to anything more than
>> the overly basic QJSEngine API just yet.
>
>
> This is true for all new features. Fearing mista
> Pick the wrong interface classes, like QtScript did, and you suffer in
> the long term. That's why we aren't committing to anything more than
> the overly basic QJSEngine API just yet.
This is true for all new features. Fearing mistakes however means no
innovation and no progress. But of course
On Thu, Nov 14, 2013 at 9:31 AM, Thiago Macieira
wrote:
> On quinta-feira, 14 de novembro de 2013 17:25:08, Tony Van Eerd wrote:
>> > But that's a long term plan, v4vm isn't even released yet (new in 5.2
>> > remember) and there's still tons of work to do. Until v4vm is ready to
>> > take over fro
On quinta-feira, 14 de novembro de 2013 17:25:08, Tony Van Eerd wrote:
> > But that's a long term plan, v4vm isn't even released yet (new in 5.2
> > remember) and there's still tons of work to do. Until v4vm is ready to
> > take over from QtScript, which will still be a while, I believe the
> > rec
>
> But that's a long term plan, v4vm isn't even released yet (new in 5.2
> remember) and there's still tons of work to do. Until v4vm is ready to
> take over from QtScript, which will still be a while, I believe the
> recommendation is to keep using QtScript. It's deprecated and "done"
> because
On quinta-feira, 14 de novembro de 2013 09:39:29, Stephen Kelly wrote:
> `QLibraryPrivate::load_sys()':
> qlibrary_unix.cpp:(.text+0x1230): warning: Using 'dlopen' in statically
> linked applications requires at runtime the shared libraries from the
> glibc version used for linking
> /home/stephe
On quinta-feira, 14 de novembro de 2013 13:27:42, Koehne Kai wrote:
> I guess what Ossi was wondering about was ' the commit message [should]
> state why this change belongs into the release branch' . It would be IMO
> weird to have sentences starting with 'This patch has to go into the
> release b
On Thu, Nov 14, 2013 at 8:01 AM, Topi Mäenpää wrote:
> On 11/14/2013 04:43 PM, Robin Burchell wrote:
>> On Thu, Nov 14, 2013 at 3:08 PM, Topi Mäenpää
>> wrote:
>>> Or rather could, if the interface wasn't a moving target.
>>
>> If an interface is a moving target, that means that trying to promis
On 11/14/2013 04:43 PM, Robin Burchell wrote:
> On Thu, Nov 14, 2013 at 3:08 PM, Topi Mäenpää
> wrote:
>> Or rather could, if the interface wasn't a moving target.
>
> If an interface is a moving target, that means that trying to promise
> compatibility for it is generally a bad idea.
I don't qu
On Thu, Nov 14, 2013 at 3:08 PM, Topi Mäenpää wrote:
> Or rather could, if the interface wasn't a moving target.
If an interface is a moving target, that means that trying to promise
compatibility for it is generally a bad idea.
Once something is made public, you're stuck with it. For a very lon
> Can you please elaborate a little bit more what you want to say by:
>
> ".. discussions about buying Digia's development resources to the project."
>
That is to say: "I'm a paying customer, so please pay attention" :) I
even used to have a commercial license, but now I'm working for a new
empl
> It sounds like an interesting project.
>
> I just wonder why you prefer "pure" Javascript over QML? It's not so
> hard to expose C++ objects or classes to QML, depending on whether
> you want to use pre-created objects or create instances via QML
> declarations. Are there some JS examples which
On Oct 29, 2013, at 7:58 PM, Calogero Mauceri wrote:
> The Qt documentation states that QDir::currentPath() returns "The
> application working directory". Shouldn't the workind directory be
> initialized with the path the application was launched from?
No, it will be initialized with whateve
Hi, I'm just setting up an instance of it, I don't know if it will really
compile
something like Qt but it's worth a try. Beats using a virtual machine. It's
free
for less than a 5 person team. You can use git. Now if they would execute
the binary it in the cloud too to test it I would be much less
On Nov 11, 2013, at 3:38 AM, Topi Mäenpää wrote:
> V8 was touted as the unifying solution for Qt JavaScript support. It
> really would have made sense to use the same script engine everywhere. I
> feared that the script engine would be changed once again and discussed
> with Digia guys before
Hi,
[...]
>
> I'm the author of Into (http://intopii.com/into,
> https://github.com/topiolli/into/) and a long-time Qt programmer since
> version 3. I'm currently in charge of designing a new generation machine
> vision platform that builds on Qt. To add some weight to this I'd like
> to me
--
Kai Köhne, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> -Original Message-
> From: development-bounces+ka
On 11 Nov 2013, at 9:38 AM, Topi Mäenpää wrote:
> Consequently, I have needed to hack my extensions by using hidden
> low-level APIs. As mentioned, this was just a matter of finding a
> pointer to the internal QScriptEngine in Qt4. In Qt5, I have used the V8
> API directly. Now that 5.2 uses a n
On 14.11.13 13:50, "Oswald Buddenhagen"
wrote:
>On Thu, Nov 14, 2013 at 07:52:27AM +, Knoll Lars wrote:
>> On 13.11.13 13:38, "Oswald Buddenhagen"
>>wrote:
>> >or to put is a bit concisely, the proposal is to simply pay attention
>>to
>> >the existing rules consistently instead of creating
On Thu, Nov 14, 2013 at 07:52:27AM +, Knoll Lars wrote:
> On 13.11.13 13:38, "Oswald Buddenhagen" wrote:
> >or to put is a bit concisely, the proposal is to simply pay attention to
> >the existing rules consistently instead of creating an entirely
> >unnecessary "paper trail".
>
> I agree wit
Hi,
A couple of weeks ago, I wrote about this issue on Qt forums
(https://qt-project.org/forums/viewthread/33278/) and was advised to
bring it up here. So, here it goes again.
I'm the author of Into (http://intopii.com/into,
https://github.com/topiolli/into/) and a long-time Qt programmer sinc
On Nov 14, 2013, at 10:25 AM, Helmut Mülner wrote:
> HI,
>
> if I use a Label (QtQuick.Controls 1.1) the QtCreator syntax checker does not
> recognize its attributes, e.g.:
>
>
> import QtQuick 2.1
> import QtQuick.Controls 1.1
>
> ApplicationWindow {
> title: qsTr("Hello World")
>
HI,
if I use a Label (QtQuick.Controls 1.1) the QtCreator syntax checker does
not recognize its attributes, e.g.:
import QtQuick 2.1
import QtQuick.Controls 1.1
ApplicationWindow {
title: qsTr("Hello World")
width: 640
height: 480
Label {
text: qsTr("
Actually all of these failures shown in
https://codereview.qt-project.org/#change,70990 seems to be caused by the
following change:
http://codereview.qt-project.org/71009 [PS1] - Fix possible crashes in QTreeView
So I wouldn't say that it is caused by the tests...
Jan Arve
> -Original M
Hello,
I get build errors when trying to build qtbase dev branch for raspbian.
/home/stephen/dev/src/qtbase/configure -prefix /usr -release -device linux-
rasp-pi-g++ -make libs -device-option CROSS_COMPILE=/home/stephen/rpi/gcc-4.7-
linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf- -sysroot /hom
27 matches
Mail list logo
