Re: [Development] QDoc can't ignore Q_PROPERTY
> On 03/10/2012 07:32 PM, ext Andre Somers wrote: > > Signals are often used outside the context of properties. > > Signals yes, but NOTIFY signals? > > This change only affects signals marked as NOTIFY in a Q_PROPERTY macro. I think the point is there may be instances where a signal that is emitted incidentally when a property changes is used as the notify signal for that property. I get not wanting to be forced into writing redundant 'emitted when this property has changed' documentation but excluding documentation that has been written for a signal seems a bit excessive, wouldn't it be enough to just omit the warning for an undocumented signal if it's a notify signal? Andrew > > > I'm already not all that enthousiastic about not having the getters > > and the setters documented explicitly*, and now people will have to > > start looking at several places in the documentation to find out what > > signals there are too. > > This doesn't change the class overview. It only changes where links point to. > > So you can still see that the class has members foo, setFoo and fooChanged > but the links point to 1 place, the property documentation. > > When you have a property, the getter, setter and notifier are > implementation details that don't matter to the property user. > > > I think there are even cases where a pair of getters& setters is only > > _documented_ as a property, but it is not defined as a Q_PROPERTY so > > anyone trying to use them using the properties API is at a loss at why > > that does not work... > > You can't document members as a property without using Q_PROPERTY. > > -- > Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, > Nokia - http://qt.nokia.com/ > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML engine C++ class renaming
> On quinta-feira, 16 de fevereiro de 2012 14.56.08, Stephen Kelly wrote: > > On Thursday, February 16, 2012 14:50:32 Olivier Goffart wrote: > > > On Thursday 16 February 2012 13:39:14 lars.kn...@nokia.com wrote: > > > > Well, it's working for the moment, so the question is where the > > > > person comes from that is willing to keep it alive. Since we'll > > > > keep BC after 5.0, the work would mainly be to adjust to changes > > > > in private headers and internals. > > > > > > So if one wants to change the private header in qtbase while > > > implementing a new feate, who is responsible to port QtQuick1? The > > > one making the change, or the QtQuick1 maintainers? > > > > > > Because if it is the one making the change, then it becomes a burden > > > for the developers in qtbase. > > > > Isn't the same true in the QML2 stuff? > > Yes, it is more or less the same still. > > It's a shared responsibility to fix those issues arising from changing of > internal API. But the point is that there are people to share it with: the one > who made the modification to the internal API in the first place and the > person who understands the code that got broken. > > In the absence of either person, it's a nightmare. Which is why I really don't > want a release *at all* unless there's someone to work with when changes > to QtCore do happen. I don't want another ActiveQt on our hands, one that > is used by lots of people and using a lot more internal API. Based on the effort required to port QtQuick1 from 4.8 to Qt5 it is isn't nearly as brittle as you're making it out to be. The only real incompatibilities have been due to changes in public API for input methods, accessibility which equally affected QtWidgets,, otherwise it's almost unchanged except for license headers . As far as use of private API goes there's surprisingly little. Excluding private object inheritance I've found uses QObjectPrivate , QMetaObjectBuilder, QBezier, QWidgetLineControl, QWidgetTextControl and a mostly the same but optimized in an incompatible manner copy of QStaticText that utilizes a few private text classes. There's not exactly a high possibility of drastic change among those classes. I'm not saying there won't be any maintenance burden, but it's not massively greater than a lot of other modules either. Andrew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Drag and Drop events.
Does anyone feel responsible for/have an interest in these? I'd like to add an overloaded constructor to QDropEvent and which takes values for the proposedAction and source properties as an alternative to the current method querying the values from a global instance of QDragManager. Something along these lines of http://codereview.qt-project.org/14209 would allow me to remove some rather silly workarounds I have in QML for sending events within a canvas independently of QDrag and the windowing system in general. Is there anything else in these that could use a touch up in the process? Global positions, a bounding rect (https://bugreports.qt.nokia.com/browse/QTBUG-2) perhaps? Andrew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
> On Wednesday, 18 de January de 2012 21.24.36, Shaw Andy wrote: > > For what it is worth I also agree that it should be changed, having > > recently having to deal with the QDoubleValidator problem when it came > > to this became a right pain so making it only use the C locale unless > > explicitly told otherwise would be fine by me > > Note we're suggesting that UI components and widgets should default to > the system locale, not the C locale. But they should have a setLocale for > changing if necessary. Should have? They already do http://developer.qt.nokia.com/doc/qt-4.8/qvalidator.html#setLocale, from the sounds of things it's just the fallback to the C locale that needs to go away. It's not exposed in QML though, I should probably do something about that. https://bugreports.qt.nokia.com/browse/QTBUG-23713 Andrew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Text clipping in QtQuick 2.0
It's a bug. https://bugreports.qt.nokia.com/browse/QTBUG-23670
Specifically items are being clipped to their boundingRect's, for which some
item's quite logically return their painted size and so are never clipped.
Text and Image are I think the only ones that do this.
Andrew
From: development-bounces+andrew.den-exter=nokia@qt-project.org
[mailto:development-bounces+andrew.den-exter=nokia@qt-project.org] On
Behalf Of Rose Todd (Nokia-M/Alpharetta)
Sent: Tuesday, January 17, 2012 3:42 PM
To: development@qt-project.org
Subject: Re: [Development] Text clipping in QtQuick 2.0
Doh! That should read "Text elements...are *not* being clipped..."
From:
development-bounces+todd.rose=nokia@qt-project.org<mailto:development-bounces+todd.rose=nokia@qt-project.org>
[mailto:development-bounces+todd.rose=nokia@qt-project.org]<mailto:[mailto:development-bounces+todd.rose=nokia@qt-project.org]>
On Behalf Of ext todd.r...@nokia.com<mailto:todd.r...@nokia.com>
Sent: Tuesday, January 17, 2012 12:34 AM
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: [Development] Text clipping in QtQuick 2.0
Text elements with wrapMode: Text.NoWrap are being clipped when the text
painted width exceeds the element width. Seems like a big regression from
QtQuick1.x...is this a known issue? Bug? Feature?
Simple example:
TextBug.qml
import QtQuick 2.0
Rectangle {
width: 360
height: 360
Rectangle {
id: leftRect
anchors.left: parent.left
anchors.top: parent.top
anchors.bottom: parent.bottom
width: 60
color: "red"
}
Rectangle {
id: rightRect
anchors.right: parent.right
anchors.top: parent.top
anchors.bottom: parent.bottom
width: 60
color: "red"
}
Text {
id: bugText
anchors.left: leftRect.right
anchors.right: rightRect.left
anchors.verticalCenter: parent.verticalCenter
wrapMode: Text.NoWrap
font.pointSize: 16
clip: true
text: "Hello World! Hello World! Hello World! Hello World! Hello World!
Hello World! Hello World! Hello World! Hello World! Hello World!"
}
MouseArea {
anchors.fill: parent
onClicked: {
if (bugText.wrapMode == Text.NoWrap)
bugText.wrapMode = Text.WordWrap
else
bugText.wrapMode = Text.NoWrap
}
}
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QTextControl and QLineControl
Sometime during the refactor QTextEdit and QLineEdit acquired their own copies of these classes leaving QtDeclarative as the only user of this private API that I'm aware of. Coordinating bug fixes that required patches to one of these classes in qtbase and and TextInput or TextEdit in qtdeclarative was an acceptable complication when it was a shared code base, if it's not shared then we have unnecessary maintenance overhead in and we're essentially circumventing CI for these classes as the only tests are in the qtdeclarative repo. So my question is, is there some plan for these classes that justifies keeping them in qtbase or can I move them to qtdeclarative where they'd be more maintainable? Andrew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
