Hi,
On Wed, Mar 7, 2012 at 5:48 PM, Lincoln Ramsay wrote:
> On 03/03/2012 02:25 AM, ext Thiago Macieira wrote:
>> On sexta-feira, 2 de março de 2012 18.01.15, Denis Shienkov wrote:
>>> The fact is that if the names of class methods and the same properties names
>>> - then QDoc ignores the descrip
On 03/03/2012 02:25 AM, ext Thiago Macieira wrote:
> On sexta-feira, 2 de março de 2012 18.01.15, Denis Shienkov wrote:
>> The fact is that if the names of class methods and the same properties names
>> - then QDoc ignores the description for the methods.
>
> That's intentional. You document the pr
Hi
What I have to say is that Qt5 is really cool, I love it ^_^
But I get a problem, I want to show some lovely tools in desktop, in order
to move them freely, I want to set the window Translucent and show the app in
FullScreen mode(or in available screen geometry). In Qt4 I can set
Qt::W
On Wed, Mar 07, 2012 at 10:33:15AM -0300, Alexis Menard wrote:
> 2012/3/7 Sean Farrow :
> > Hi All:
> >
> > I’m just investigating the qt widgdets for qt5.
> >
> > I have a list of qt widgets for qt4.7:
> >
> > http://doc.qt.nokia.com/4.7-snapshot/widgets-and-layouts.html
> >
> > are there any othe
Hi there,
I started looking into moving the dbus tools to qtbase.git.
This came up before and the conclusion was to move the dbus tools to where
dbus is:
http://thread.gmane.org/gmane.comp.lib.qt.devel/764/focus=80
I tried to bootstrap the dbus tools, but that does not seem to be possible (or
On 3/7/12 8:18 PM, "ext Marc Mutz" wrote:
>Hi Lars,
>
>On Wednesday March 7 2012, lars.kn...@nokia.com wrote:
>> I very much agree with Andre and Jedrzej. I don't see little value added
>> here, and I actually even see quite a few useful cases for public
>> inheritance, like QPolygon.
>
>Thanks f
Bom, a exemplo, e pedido, do Antognolli estou compartilhando minha proposta de
palestra. Naturalmente sugestões são muito bem vindas.
Author: "Jonas M. Gastal"
Team leader at ProFUSION Embedded Systems
Title:
There's an ~~app~~example for that
Short bio:
Gastal has been a professional Linux de
Hi Lars,
On Wednesday March 7 2012, lars.kn...@nokia.com wrote:
> I very much agree with Andre and Jedrzej. I don't see little value added
> here, and I actually even see quite a few useful cases for public
> inheritance, like QPolygon.
Thanks for bringing up QPolygon, because I don't think good
Forwarding to the [Development] list since all the Qt 5 maintainers are here.
Please check the alpha release marketing proposal and provide the info &
pointers related to your module. Thank you!
From: Quim Gil [quim@nokia.com]
Sent: Tuesday, March 06
On Wed, Mar 07, 2012 at 08:57:03AM +0100, ext Marc Mutz wrote:
> I've uploaded a patch series that makes most of the value classes in QtCore
> final in the C++11 sense (ie. under a C++11 compiler, these can no longer be
> inherited from).
>
-1
> Value classes are meant to be be used as-is. When
On quarta-feira, 7 de março de 2012 17.17.47, Alex Strickland wrote:
> On 2012/03/07 03:25 PM, Marc Mutz wrote:
> > You shouldn't look at the Qt-project developers when discussing
> > interfaces.
> > You should look a the Qt programmers in the trenches that happily write
> > QColor * c = new QColor
On quarta-feira, 7 de março de 2012 19.36.17, Rohan McGovern wrote:
> Thanks, so can we use #pragma GCC diagnostic to selectively silence
> warnings like this? There doesn't seem to be much precedent for it so
> far (just one usage I can find in qatomic.h).
We can do that to silence the warning.
On 2012/03/07 03:25 PM, Marc Mutz wrote:
> You shouldn't look at the Qt-project developers when discussing interfaces.
> You should look a the Qt programmers in the trenches that happily write
> QColor * c = new QColor(...), as blissfully ignorant of the resource leak as
> they are of Sutter/Alexa
On 3/7/12 2:25 PM, "ext Marc Mutz" wrote:
>On Wednesday March 7 2012, Jedrzej Nowacki wrote:
>> What are you trying to solve?
>
>I'm trying to prevent that people with a Java mind from running into the
>C++
>trap that inheriting from a base class with a public non-virtual
>destructor
>may invok
2012/3/7 Sean Farrow :
> Hi All:
>
> I’m just investigating the qt widgdets for qt5.
>
> I have a list of qt widgets for qt4.7:
>
> http://doc.qt.nokia.com/4.7-snapshot/widgets-and-layouts.html
>
> are there any other new widgets in qt5 that are planned.
As stated in http://qt-project.org/wiki/Qt_
On Wednesday March 7 2012, Jedrzej Nowacki wrote:
> What are you trying to solve?
I'm trying to prevent that people with a Java mind from running into the C++
trap that inheriting from a base class with a public non-virtual destructor
may invoke undefined behaviour. Looking at the number of "add
Hi All:
I'm just investigating the qt widgdets for qt5.
I have a list of qt widgets for qt4.7:
http://doc.qt.nokia.com/4.7-snapshot/widgets-and-layouts.html
are there any other new widgets in qt5 that are planned.
Regards
Sean.
___
Development mailing lis
I very much agree with Andre and Jedrzej. I don't see little value added
here, and I actually even see quite a few useful cases for public
inheritance, like QPolygon.
So no, I'm against making value classes final.
Cheers,
Lars
On 3/7/12 1:03 PM, "ext Jedrzej Nowacki" wrote:
>On Wednesday 7. Ma
On Wednesday 7. March 2012 12.37.51 ext Marc Mutz wrote:
> On Wednesday March 7 2012, andre.poen...@nokia.com wrote:
> > Marc Mutz wote:
> > > I've uploaded a patch series that makes most of the value classes in
> > > QtCore final in the C++11 sense (ie. under a C++11 compiler, these can
> > > no l
Rohan:
Because no one more-authoritative has answered you,
I'll give it a try.
I think that this occurs because QVariant must have
sufficiently-strict alignment constraints to hold,
properly aligned, the largest POD datum that can be
stored in the variant. Other, more-specific objects
> Marc Mutz [marc.m...@kdab.com]
> > Marc Mutz wote:
> > > I've uploaded a patch series that makes most of the value classes in
> > > QtCore final in the C++11 sense (ie. under a C++11 compiler, these can no
> > > longer be inherited from).
> >
> > I disagree with the idea of making Qt core classe
Hello everyone,
The containers branch has reached a point where it would be beneficial
to have it merged with api_changes (and then master, from there). The
branch has already been tracking master closely.
The plan now is to merge api_changes once more into containers and have
that go through CI
On Wednesday March 7 2012, andre.poen...@nokia.com wrote:
> Marc Mutz wote:
> > I've uploaded a patch series that makes most of the value classes in
> > QtCore final in the C++11 sense (ie. under a C++11 compiler, these can no
> > longer be inherited from).
>
> I disagree with the idea of making Qt
Marc Mutz wote:
> I've uploaded a patch series that makes most of the value classes in QtCore
> final in the C++11 sense (ie. under a C++11 compiler, these can no longer be
> inherited from).
I disagree with the idea of making Qt core classes non-inheritable.
While inheritance from "value" clas
Thiago Macieira said:
> On quarta-feira, 7 de março de 2012 09.34.35, Rohan McGovern wrote:
> > Does anyone have a suggestion on how to fix this warning?
> >
> > This code in qlist.h:
> >
> > 409: template
> > 410: Q_INLINE_TEMPLATE void QList::node_destruct(Node *from, Node *to)
> > 411:
On 03/06/2012 10:32 PM, ext haithem rahmani wrote:
> Hi again,
> Sorry if I'm bothering you guys.
>
> I did as you suggested Samuel, and I've found that it doesn't support
> cross-compilation.
>
> I see something like this in the log:
>
> floatmath auto-detection... ()
> g++ -c
On quarta-feira, 7 de março de 2012 09.34.35, Rohan McGovern wrote:
> Does anyone have a suggestion on how to fix this warning?
>
> This code in qlist.h:
>
> 409: template
> 410: Q_INLINE_TEMPLATE void QList::node_destruct(Node *from, Node *to)
> 411: {
> 412:if (QTypeInfo::isLarge ||
Hi,
I've uploaded a patch series that makes most of the value classes in QtCore
final in the C++11 sense (ie. under a C++11 compiler, these can no longer be
inherited from). The changesets, for reference, are
http://codereview.qt-project.org/19008
thu
http://codereview.qt-project.org/19024
28 matches
Mail list logo
