Den 11-04-2012 04:03, 程梁 skrev:
> I have read this article:
>
> http://arstechnica.com/business/news/2012/04/an-in-depth-look-at-qt-5-making-javascript-a-first-class-citizen-for-native-cross-platform-developme.ars
>
> , there I found a word:
>
> "C++ would then typically only be used to implement p
I am new to QT 4.0. I have a QGraphicsItem subclass which I need to
constrain its positioning when it is dragged on the screen by the mouse.
For example, if another of these objects is visible on the screen, I want
to be sure the x coordinate of the new one is always >= to the old. Also I
want t
I have read this article:
http://arstechnica.com/business/news/2012/04/an-in-depth-look-at-qt-5-making-javascript-a-first-class-citizen-for-native-cross-platform-developme.ars
, there I found a word:
"C++ would then typically only be used to implement plugin libraries
that extend the capabilitie
On terça-feira, 10 de abril de 2012 19.18.33, Bob Hood wrote:
> On 4/10/2012 5:01 PM, Thiago Macieira wrote:
> > So I repeat again the call for help: if you're interested in seeing this
>
> happen sooner rather than later, help out. /Especially if you're interested
> in the desktop more than mobile
On 4/10/2012 5:01 PM, Thiago Macieira wrote:
> So I repeat again the call for help: if you're interested in seeing this
happen sooner rather than later, help out. /Especially if you're interested in
the desktop more than mobile./
That statement bothers me a bit. Am I reading too much into what y
On terça-feira, 10 de abril de 2012 22.46.38, Paul Floyd wrote:
> On 10 Apr 2012, at 22:28, Thiago Macieira wrote:
> > On terça-feira, 10 de abril de 2012 21.44.49, Paul Floyd wrote:
> >>> As for Qt 5, since locking and unlocking is inlined into the user code,
> >>> valgrind might be completely una
On terça-feira, 10 de abril de 2012 23.44.54, Nikos Chantziaras wrote:
> > I wish we could do the same for Qt. Keeping it linking statically is very
> > hard and we break every other release because no one tests.
> >
> > BTW, it's known to be broken in Qt 5.
>
> So goodbye to self-contained executa
On 04/09/2012 05:36 AM, ext Artur Adib wrote:
> Greetings everyone,
>
> I am a Node.js *and* Qt fan, so I thought I'd combine both worlds and
> bring some graphics/audio capabilities to Node.js via Qt:
>
> https://github.com/arturadib/node-qt
>
> I've worked hard to make the installation/build work
On Tue, 10 Apr 2012 23:44:54 +0300, Nikos Chantziaras
wrote:
> So goodbye to self-contained executables? That doesn't sound like a
> good idea :-/ Being able to ship a single *.exe is quite a nice thing
> to have.
"Self-contained" is not the same as static linking! Actually, I build
binaries t
On 10 Apr 2012, at 22:28, Thiago Macieira wrote:
> On terça-feira, 10 de abril de 2012 21.44.49, Paul Floyd wrote:
>>> As for Qt 5, since locking and unlocking is inlined into the user code,
>>> valgrind might be completely unable to work.
>>
>> If the code is inline, then all I can think of wo
On 10/04/12 23:23, Thiago Macieira wrote:
>> And I don't need an installer. People value single executables that can
>> be copied and run from everywhere (internal hard disks, USB flash
>> sticks, whatever.) And I'm not sure I could link KDE statically into a
>> single *.exe like I do with Qt (an
I agrees 100% with Nikos
On 10/04/2012, at 21:53, Nikos Chantziaras wrote:
> On 10/04/12 22:38, Thiago Macieira wrote:
>> On terça-feira, 10 de abril de 2012 22.30.54, Nikos Chantziaras wrote:
>>> On 10/04/12 22:24, Thiago Macieira wrote:
On terça-feira, 10 de abril de 2012 22.07.49, Niko
Hi again,
I created a dummy project to test some things. You can find the project
here : https://bitbucket.org/hiveNzin0/qtunittest
I would like to know if it is "clean" to do like I did in the main.cpp in
tests/unitTests ? That's the result I wanted.
I tried to create on project for each class b
On terça-feira, 10 de abril de 2012 21.44.49, Paul Floyd wrote:
> > As for Qt 5, since locking and unlocking is inlined into the user code,
> > valgrind might be completely unable to work.
>
> If the code is inline, then all I can think of would be to recognise the
> opcode sequence and proceed fro
On terça-feira, 10 de abril de 2012 22.53.01, Nikos Chantziaras wrote:
> Bundling KDE libs? It's much simpler to not use KDE functionality.
> Otherwise you end up with a big size that is unsuitable for small
> utility applications.
Ah, but sometimes you end up either reinventing the wheel (comman
On 11/04/2012, at 5:53 AM, ext Nikos Chantziaras wrote:
> On 10/04/12 22:38, Thiago Macieira wrote:
>> On terça-feira, 10 de abril de 2012 22.30.54, Nikos Chantziaras wrote:
>>> On 10/04/12 22:24, Thiago Macieira wrote:
On terça-feira, 10 de abril de 2012 22.07.49, Nikos Chantziaras wrote:
>
On 10/04/12 22:38, Thiago Macieira wrote:
> On terça-feira, 10 de abril de 2012 22.30.54, Nikos Chantziaras wrote:
>> On 10/04/12 22:24, Thiago Macieira wrote:
>>> On terça-feira, 10 de abril de 2012 22.07.49, Nikos Chantziaras wrote:
> Which is a pity. There's a lot of functionality in the KDE
On 10 Apr 2012, at 14:56, Thiago Macieira wrote:
>
> That's not correct. Valgrind's helgrind had support for QMutex specifically.
> Helgrind needed to know when a mutex was locked or unlocked, in order to
> present its warnings. To do that, it specifically overrides the QMutex::lock
> and unl
Sound idiotic, but it would be an improvement.
From: Nikos Chantziaras
To: interest@qt-project.org
Sent: Tuesday, April 10, 2012 3:30 PM
Subject: Re: [Interest] QtArg
On 10/04/12 22:24, Thiago Macieira wrote:
> On terça-feira, 10 de abril de 2012 22.07.49, N
On terça-feira, 10 de abril de 2012 22.30.54, Nikos Chantziaras wrote:
> On 10/04/12 22:24, Thiago Macieira wrote:
> > On terça-feira, 10 de abril de 2012 22.07.49, Nikos Chantziaras wrote:
> >>> Which is a pity. There's a lot of functionality in the KDE libs that you
> >>> should use. You should c
On 10/04/12 22:24, Thiago Macieira wrote:
> On terça-feira, 10 de abril de 2012 22.07.49, Nikos Chantziaras wrote:
>>> Which is a pity. There's a lot of functionality in the KDE libs that you
>>> should use. You should consider transforming your Qt-only app into a KDE
>>> one.
>> That is really bad
On terça-feira, 10 de abril de 2012 22.07.49, Nikos Chantziaras wrote:
> > Which is a pity. There's a lot of functionality in the KDE libs that you
> > should use. You should consider transforming your Qt-only app into a KDE
> > one.
> That is really bad advise :-/ It would mean non-KDE users (abo
On 10/04/12 21:46, Thiago Macieira wrote:
> On terça-feira, 10 de abril de 2012 21.15.29, Nikos Chantziaras wrote:
>> On 10/04/12 17:32, Thiago Macieira wrote:
>>> On terça-feira, 10 de abril de 2012 17.17.09, Nikos Chantziaras wrote:
I'd recommend to support Igor Mironchik instead, since it's
Nikos Chantziaras wrote:
> On 10/04/12 17:32, Thiago Macieira wrote:
>> On terça-feira, 10 de abril de 2012 17.17.09, Nikos Chantziaras wrote:
>>> On 10/04/12 15:54, Thiago Macieira wrote:
On terça-feira, 10 de abril de 2012 12.00.18, Igor Mironchik wrote:
> Here is very simple command li
On terça-feira, 10 de abril de 2012 21.15.29, Nikos Chantziaras wrote:
> On 10/04/12 17:32, Thiago Macieira wrote:
> > On terça-feira, 10 de abril de 2012 17.17.09, Nikos Chantziaras wrote:
> >> I'd recommend to support Igor Mironchik instead, since it's for Qt 4,
> >> which we will be using for a
On 10/04/12 17:32, Thiago Macieira wrote:
> On terça-feira, 10 de abril de 2012 17.17.09, Nikos Chantziaras wrote:
>> On 10/04/12 15:54, Thiago Macieira wrote:
>>> On terça-feira, 10 de abril de 2012 12.00.18, Igor Mironchik wrote:
Here is very simple command line arguments parser.
L
On terça-feira, 10 de abril de 2012 17.24.48, Igor Mironchik wrote:
> 10.04.2012 17:17, Nikos Chantziaras wrote:
> >> There's another one being developed for Qt 5:
> >>
> >> http://qt.gitorious.org/qt/qtbase/commits/cli_parser
> >>
> >> I recommend everyone who has ever developed a parser to join L
On terça-feira, 10 de abril de 2012 17.17.09, Nikos Chantziaras wrote:
> On 10/04/12 15:54, Thiago Macieira wrote:
> > On terça-feira, 10 de abril de 2012 12.00.18, Igor Mironchik wrote:
> >> Here is very simple command line arguments parser.
> >>
> >> Look at it: http://code.google.com/p/qtargpars
10.04.2012 17:17, Nikos Chantziaras wrote:
>> There's another one being developed for Qt 5:
>>
>> http://qt.gitorious.org/qt/qtbase/commits/cli_parser
>>
>> I recommend everyone who has ever developed a parser to join Laszlo's effort
>> to
>> make sure we meet your needs by Qt 5.1.
I can't find c
Hi,
thanks again for all the informations. I think I will create another test
project to experiment a lot with the Qt Test Lib and see what I can do and
not do.
I didn't understand how you call them automatically when you do automated
test proc. You have one main for each file (test class), do yo
On 10/04/12 15:54, Thiago Macieira wrote:
> On terça-feira, 10 de abril de 2012 12.00.18, Igor Mironchik wrote:
>> Here is very simple command line arguments parser.
>>
>> Look at it: http://code.google.com/p/qtargparser/
>
> There's another one being developed for Qt 5:
>
> http://qt.gitorious.org
On terça-feira, 10 de abril de 2012 13.35.24, pa...@free.fr wrote:
> - Original Message -
>
> > Hi all...what's the best tool to detect threading errors in qt5 based
> > code?
> > Are valgrind's drd and helgrind tools reliable for qt5 code?
> > AFAIK they include some support for qt4 based
On terça-feira, 10 de abril de 2012 12.00.18, Igor Mironchik wrote:
> Here is very simple command line arguments parser.
>
> Look at it: http://code.google.com/p/qtargparser/
There's another one being developed for Qt 5:
http://qt.gitorious.org/qt/qtbase/commits/cli_parser
I recommend everyone w
- Original Message -
> Hi all...what's the best tool to detect threading errors in qt5 based
> code?
> Are valgrind's drd and helgrind tools reliable for qt5 code?
> AFAIK they include some support for qt4 based clients, but I also
> know Qmutex has changed quite a lot in qt5, so I wonder i
Hi all...what's the best tool to detect threading errors in qt5 based code?
Are valgrind's drd and helgrind tools reliable for qt5 code?
AFAIK they include some support for qt4 based clients, but I also know Qmutex
has changed quite a lot in qt5, so I wonder if the results we get now for qt5
code
The best answer i can give you is: it depends. I like to have a test project
per class so i can run them manually while writing the related class and have
them automatically called when doing automated test procedures.
Have a look at the subdir template. Basically, you will end with several
sub
Hi,
I have to look for informations about how to separate my project to create
a library then.
Is it better to have a small project for each test class ? I have poor
knowledge of unit testing of course but wouldn't it be more clear to have a
big project containing all the unit test to start from
Here is very simple command line arguments parser.
Look at it: http://code.google.com/p/qtargparser/
This project needs you donations.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Good day.
My name is Igor Mironchik. I live in Belarus. After graduating I worked
as a programmer in the company "Intervale". Everything was just
wonderful. I had a good salary, a wonderful team. But in March 2010 I
had to resign from the company. And from that moment my life went on
down. Se
On 10 avr. 2012, at 10:29, Gilles Habran wrote:
> Hi guys,
>
> I have a personal project and I would like to try to use Test Driven
> Development. For the moment, my only knowledge in Unit Tests come from
> several books, I never really use that concept in a project.
>
> Here is the arch of m
Hi guys,
I have a personal project and I would like to try to use Test Driven
Development. For the moment, my only knowledge in Unit Tests come from
several books, I never really use that concept in a project.
Here is the arch of my project folder :
xxx/xxx.pro
xxx/src/*.cpp
xxx/include/*.h
xxx/
41 matches
Mail list logo
