Re: [Development] Role names and Proxy Models
Hi Johan,
Please reply to the list.
On Monday, January 16, 2012 08:22:48 you wrote:
2012/1/16 Stephen Kelly stephen.ke...@kdab.com:
I'm not sure what your actual proposal is?
My issue is that the role names of a proxy model are taken directly
from the model being proxied, i.e. the following lines from
qabstractproxymodel.cpp (around line 135, in
QAbstractProxyModel::setSourceModel, Qt 4.8):
...
}
d-roleNames = d-model-roleNames();
}
...
This overrides any attempts to use setRoleNames in a proxymodel, to
do, for instance, role-name.transformations.
How so? This works:
MyProxyModel::setSourceModel(...)
{
// ...
BaseProxy::setSourceModel(...);
// ...
setRoleNames(...);
}
My impression is that this did not work correctly with 4.8, but all I
really confirmed was that I got questions for the wrong role numbers.
The core reason for this, is that Qt 4.8 forces the wrong role names
onto the proxy models.
How does it force the wrong role names onto proxy models?
A virtual method looks handy, makes it possible to do what I want to.
However, the default role name setting in
QAbstractProxyModel::setSourceModel is still present in Qt 5.0.
Does it make more sense now? :-)
I'm afraid I don't see why the above setSourceModel implementation wouldn't
work.
Thanks,
--
Stephen Kelly stephen.ke...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QTextFragment visibility option
Hello everybody, As it is my first post in that list, a bit of presentation is due: my name is Pierre Stirnweiss, and I am part of the Calligra (www.calligra.org) team. I initially started coding in KOffice time, with the initial implementation of the change tracking system. We (as in the Calligra team) would like to discuss a feature we need from the QTextFragment: being able to toggle the visibility (ie, laying out and painting) of a specific QTextFragment. 1. the initial use case for Calligra Words: change tracking for deletions. When tracked, a delete text fragment shouldn't actually be sent to limbo: it should be marked as deleted. When the text is visualized with highlighting the changes, the deleted fragments can be displayed in 2 ways: inline or as side notes. When the text is visualized without highlighting the changes, the deleted fragments shouldn't appear at all. We want to implement the display of changes inline, hence the need of being able to layout/draw text fragments depending on the show/hide changes. For now, Qt does not allow to not layout/display a fragment of text. The way we are currently working around that problem in Calligra is the following: when the user hides the changes, the deleted fragments are actually deleted from the QTextDocument, when the user toggles to show changes the deleted fragments are re-inserted in the QTextDocument. The problem with that solution is first that this creates an undo/redo insertion/deletion for what is actually just a display option. The second is that it renders the code in Calligra very complex, especially with regards to style, save, cursor. 2. second important use case for Calligra Words: substitution characters for objects (anchors,...). Although these characters are not displayed within the text (because their size is returned as 0 width), they are still laid out. This means that on cursor movement, they are not traversed. This means the user need to press several times the arrow key to go through what appears as a single cursor position on screen. 3. further interesting use case (but which is not yet that stringent for Calligra Words): hiding portions of text on demand This can be interesting for example in case of multiple user editing. Some portions of text might be irrelevant/confidential (although for confidentiality, this would be a very very weak solution) for some users and not for others. Another use case of that type is similar for example to IDE code folding. I am not interested in seeing this part of the text (like in IDE an if block), so I would like to hide it for now. That is for a bit of background on the use cases. About a year or two ago, we discussed this problematic of having visible/invisible QTextFragments. 2 initial ideas for solution appeared: - have a boolean in the QTextFragment toggling visibility or not. the layout engine would lay out only the visible fragments. The advantages of this solution is that since the visibility would be a layout/display only property, a bool on the fragment wouldn't trigger any undo/redo actions in QTextDocument. The second advantage is that there is no need to tweak/touch the text formatting mechanism. The drawback is an added visible bool member to the QTextFragment API. - have a visible character format. The layout engine would get passed a flag if it should layout these fragments or not. The advantage of this is that the visible impact on the API is probably less. The inconvenient is that setting a character format is triggering an undo/redo action in QTextDocument. Also, the layout should probably be tweaked deeper than with the other solution. Ganesh Paramasivam (who was i think at the time mandated by Nlnet to work on change tracking in KOffice) started working on this (using the first solution, which looked like the most logical one) and submitted a patch to Qt (https://qt.gitorious.org/qt/qt/merge_requests/2274), which triggered some discussion. At some point the merge request was rejected. Now with Qt5 coming, it would be a really good time to actually get this to a conclusion, because this feature is actually really needed. CBoemann who is maintaining Calligra Words has updated the initial patch (to avoid the extra memory footprint) and submitted a Gerrit review request: http://codereview.qt-project.org/#change,13161 for this. PierreSt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Role names and Proxy Models
On Monday 16 January 2012 02:13:44 Stephen Kelly wrote: [...] If QML doesn't re-read the rolenames when the model is reset, then there's a patch to be made in QtDeclarative. (QAbstractProxyModel doesn't re-read them on reset either. Ogoffart rejected my patch to make it do that for reasons which never made sense to me and which I now forget and can't find on the internet). I don't recall all the details either, but if I remember correctly, your patch was doing things that were not allowed. The role name feature is a bit broken as you can't really modify them. (As usual with features that are added to Qt in a rush by the decarative team for their own use cases, without much thinking ahead) The documentation say: This function allows mapping of role identifiers to role property names in Declarative UI. This function must be called before the model is used. Modifying the role names after the model has been set may result in undefined behaviour. And you were calling it while the model was already in use, and I think it was the reason why I rejected. Anyway the Qt 5.0 way to set rolenames is to implement a virtual method. Please see if that addresses your concern, and if it doesn't, then please write an example which doesn't require a proxy which hides 'multiple underlying models'. That might not work anyway for various reasons (if you are using QAbstractProxyModel). Use an example such as 'a proxy model which returns a string filename for an image instead of a QImage for the decoration role'. I think Qt 5 still do not implement ways to notify that the role name change. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Role names and Proxy Models
On 16 January 2012 12:21, Olivier Goffart oliv...@woboq.com wrote: I think Qt 5 still do not implement ways to notify that the role name change. Proper signals to handle that (along the lines of all other QAIM signals) can always be added after 5.0, right? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Role names and Proxy Models
On Monday, January 16, 2012 13:21:19 you wrote: On Monday 16 January 2012 02:13:44 Stephen Kelly wrote: [...] If QML doesn't re-read the rolenames when the model is reset, then there's a patch to be made in QtDeclarative. (QAbstractProxyModel doesn't re-read them on reset either. Ogoffart rejected my patch to make it do that for reasons which never made sense to me and which I now forget and can't find on the internet). I don't recall all the details either, but if I remember correctly, your patch was doing things that were not allowed. The role name feature is a bit broken as you can't really modify them. (As usual with features that are added to Qt in a rush by the decarative team for their own use cases, without much thinking ahead) The documentation say: This function allows mapping of role identifiers to role property names in Declarative UI. This function must be called before the model is used. Modifying the role names after the model has been set may result in undefined behaviour. And you were calling it while the model was already in use, and I think it was the reason why I rejected. Yes, I think that was it. Bad documentation IMO. Resetting the model means you have to read everything from it from scratch. It is very much well enough defined IMO that resetting the model might mean that it has different role names. Anyway the Qt 5.0 way to set rolenames is to implement a virtual method. Please see if that addresses your concern, and if it doesn't, then please write an example which doesn't require a proxy which hides 'multiple underlying models'. That might not work anyway for various reasons (if you are using QAbstractProxyModel). Use an example such as 'a proxy model which returns a string filename for an image instead of a QImage for the decoration role'. I think Qt 5 still do not implement ways to notify that the role name change. Resetting the model means 'everything just changed'. The rolenames are part of 'everything'. I think all it takes is fixing the documentation for Qt 5 to make that clearer for you. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Role names and Proxy Models
On Monday 16 January 2012 13:48:33 Stephen Kelly wrote: On Monday, January 16, 2012 13:21:19 you wrote: On Monday 16 January 2012 02:13:44 Stephen Kelly wrote: [...] If QML doesn't re-read the rolenames when the model is reset, then there's a patch to be made in QtDeclarative. (QAbstractProxyModel doesn't re-read them on reset either. Ogoffart rejected my patch to make it do that for reasons which never made sense to me and which I now forget and can't find on the internet). I don't recall all the details either, but if I remember correctly, your patch was doing things that were not allowed. The role name feature is a bit broken as you can't really modify them. (As usual with features that are added to Qt in a rush by the decarative team for their own use cases, without much thinking ahead) The documentation say: This function allows mapping of role identifiers to role property names in Declarative UI. This function must be called before the model is used. Modifying the role names after the model has been set may result in undefined behaviour. And you were calling it while the model was already in use, and I think it was the reason why I rejected. Yes, I think that was it. Bad documentation IMO. Resetting the model means you have to read everything from it from scratch. It is very much well enough defined IMO that resetting the model might mean that it has different role names. Anyway the Qt 5.0 way to set rolenames is to implement a virtual method. Please see if that addresses your concern, and if it doesn't, then please write an example which doesn't require a proxy which hides 'multiple underlying models'. That might not work anyway for various reasons (if you are using QAbstractProxyModel). Use an example such as 'a proxy model which returns a string filename for an image instead of a QImage for the decoration role'. I think Qt 5 still do not implement ways to notify that the role name change. Resetting the model means 'everything just changed'. The rolenames are part of 'everything'. I think all it takes is fixing the documentation for Qt 5 to make that clearer for you. Yes, a change in the documentatin would be enough for the qtbase part. (ok, maybe some tsts welcome as well) But declarative also need to be fixed to the fact that roles name can change. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLocale work
On Sunday 15 Jan 2012 22:53:31 Thiago Macieira wrote: On Sunday, 15 de January de 2012 23.09.35, John Layt wrote: * A QCldrLocale is not really needed for Qt purposes, it's only needed for anyone who wants to know what individual settings are, like KDE What would this class provide that the regular QLocale wouldn't? In the Locale KCM we need to know what each individual setting is so the user can change them. QLocale doesn't provide that, it's mostly just to/from routines with a few necessary settings like decimal point exposed mainly for other Qt classes like QString to use, and it really shouldn't be any more. The KCM could probably get what it needs by using QSystemLocale and directly querying ICU when QSystemLocale returns a null. Or we could change or remove the feature, but that's a flamewar for another list John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - 3D Audio module
Hi Laszlo, On 9/01/12 4:52 PM, ext Laszlo Papp lp...@kde.org wrote: The module name would be either QtOpenAL or 3D Audio. Either one works for me. I'd prefer QtOpenAL because there are other 3D audio systems (if less popular), but there may be a trademark issue. I've asked Cristy about this and I'll send another email. It is probably necessary to delay the playground initiation until after that. Any progress ? I have asked this legal question first about one month ago, but it does not seem to have any progress. I have also tried to contact Creative Labs previously without any success. Loki is out-of-the question nowadays. Sorry about the delay - there has been no progress that I've seen. I repinged again recently but will do again. Cheers, MichaelG ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[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
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.orgmailto: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.commailto:todd.r...@nokia.com
Sent: Tuesday, January 17, 2012 12:34 AM
To: development@qt-project.orgmailto: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
Re: [Development] What's the story for Qt5 on Harmattan?
On Thursday, January 12, 2012 06:50:58 AM ext xizhi@nokia.com wrote: Hi, Practically, since Qt Project has no plan to support Qt5 in Harmattan, I believe the Harmattan-specific code sits in its own clone repository (same as for QtonPi [1] and ), right? [1] https://qt.gitorious.org/qtonpi This is not correct I believe. We are doing changes in qtbase, etc. for improved support of Qt 5 on Harmattan. I don't think it will make it to tier1 with just our effort, but we have a continued interest in running qtbase/qtdeclarative on Harmattan and it would be nice to keep things working as long as the maintenance required to do that is as low as it currently seems. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
