Re: [Interest] Struggling with moveEvent()
Hi Sean, Widgets are normally positioned relative to their owner - the exception is popup menus, which are screen absolute. I would expect a popup menu to automatically close when the title bar is clicked. How have you implemented your captionPopupMenu? Does it capture the mouse when it is visible? It should close if the mouse is clicked anywhere outside its borders. Since you've got a QPushButton, did you consider using its setMenu to achieve a similar result? Regards, Tony On 2/10/2018 4:11 AM, Murphy, Sean wrote: My basic question is how do child widgets get moved or repainted when some ancestor of theirs moves? Here's the more detailed issue, first the widget hierarchy: QMainWindow CustomerHeaderTable (inherits from QTableWidget) CustomTableHeader (inherits from QHeaderView, allows you to put widgets in the header sections) dataConfigWidget (inherits from QWidget) QPushButton captionPopupMenu (inherits from QWidget, starts out hidden) What I'm trying to accomplish is when the user presses the QPushButton, that a custom popup menu (the captionPopupMenu) appears aligned to the pushbutton. Right now I've got the initial alignment working just fine. The issue is when the popup is visible, if the user then grabs the application title bar and moves the entire main window around, the popup isn't moving with the application. So I figured I just need to update the captionPopupMenu's position in dataConfigWidget's moveEvent() to keep it positioned correctly. But it appears when the main window moves around, the dataConfigWidget's moveEvent() is never called - I put some qDebug() statements in there to verify. Same goes for paintEvent() - my child widgets aren't getting called when the ancestors move. So I'm not sure what I need to trigger off from to detect when I need to reposition the menu. I feel like I'm missing something really obvious, but not seeing it on a Monday apparently. Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Struggling with moveEvent()
Il 01/10/2018 20:11, Murphy, Sean ha scritto: So I'm not sure what I need to trigger off from to detect when I need to reposition the menu. I feel like I'm missing something really obvious, but not seeing it on a Monday apparently. I don't think you're missing anything -- if a widget doesn't move, but its parent does, only the parent gets a move event, not the widget. As a result, for your use case, I believe you need to track move events on the whole parent/child chain starting at the window up to your widget. I guess you can install event filters for this. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] qmllive with android target
Have anybody succeed in configuring such an environment? I'm a bit stuck with figuring out what to specify as 'workspacePath'. Regards, Alexander ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Struggling with moveEvent()
My basic question is how do child widgets get moved or repainted when some ancestor of theirs moves? Here's the more detailed issue, first the widget hierarchy: QMainWindow CustomerHeaderTable (inherits from QTableWidget) CustomTableHeader (inherits from QHeaderView, allows you to put widgets in the header sections) dataConfigWidget (inherits from QWidget) QPushButton captionPopupMenu (inherits from QWidget, starts out hidden) What I'm trying to accomplish is when the user presses the QPushButton, that a custom popup menu (the captionPopupMenu) appears aligned to the pushbutton. Right now I've got the initial alignment working just fine. The issue is when the popup is visible, if the user then grabs the application title bar and moves the entire main window around, the popup isn't moving with the application. So I figured I just need to update the captionPopupMenu's position in dataConfigWidget's moveEvent() to keep it positioned correctly. But it appears when the main window moves around, the dataConfigWidget's moveEvent() is never called - I put some qDebug() statements in there to verify. Same goes for paintEvent() - my child widgets aren't getting called when the ancestors move. So I'm not sure what I need to trigger off from to detect when I need to reposition the menu. I feel like I'm missing something really obvious, but not seeing it on a Monday apparently. Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Priority of bugs
Tuukka Turunen wrote: > Just to note that more than “two minor fixes” were done related to widgets in > Qt 5.11.2 Sorry, my bad. I was (wrongly) basing that statement on the contents of the changelist: http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.11.2 If you filter that Jira link to widgets only its around 20, not 2, so I clearly overstated. Still, I stand by everything else I said. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] CLion + Qt?
(I'm asking here because I think my odds of finding a CLion user in a pile of Qt users is better than finding a Qt user in a bucket of CLion users). I have a medium-sized Qt+cmake project - it builds fine, Qt Creator is mostly[1] happy with it. I thought I'd give CLion a try, and it really doesn't seem to like Qt. A simple header file that has "#include " at the top has most of the QString member variables underlined in red with hover text of "Field has incomplete type 'QString'". Any use of qCWarning says "No matching function for call to qWarning". QStringLiteral says "Expected body of lambda expression". Despite all the errors in the editor it builds fine from within CLion. Has anyone used CLion with Qt successfully? If so, any suggestions for how to make it happy? Cheers, Steve [1] It has the clangbackend crashing issue, but that's about it. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Priority of bugs
Hi, Just to note that more than “two minor fixes” were done related to widgets in Qt 5.11.2 of the total 262 fixes: https://bugreports.qt.io/issues/?filter=19635 Widgets is an important area and we are actively maintaining those. There is less new development than on some other areas, but Widgets are not forgotten. This is just to point out that situation is not as bad as you said. There is always possibility to do more and there are certainly many bugs still to fix in Widgets area. Yours, Tuukka From: Interest on behalf of Krzysztof Kawa Date: Monday, 1 October 2018 at 16.30 To: "interest@qt-project.org" Subject: Re: [Interest] Priority of bugs I get that. Let me try to be more constructive then - looking at the proportion of the number of those long standing unresolved issues to the number of bullet points in the release notes by module I'd say a lot of those unlucky ones sit in the widgets area (e.g. 2 minor fixes in 5.11.2 is hardly an adequate pace). ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Priority of bugs
Alex Blasche wrote: > Fact is that Qt is huge and there are not enough work hours in a day to fix them all. I'm a maintainer of a pretty large code base myself so I understand that completely. > (...) some bugs are simply too hard to fix (...) and (...) there are things which are too risky to fix because they have an extremely high potential to break other things. Granted, but those are not the things I'm talking about. The types of bugs I'm talking about are regressions, in some cases introduced by new functionality that is buggy itself. Fixing them shouldn't be any harder than introducing them. If all else fails - revert the new feature that caused the issues. It doesn't work correctly anyway and breaks existing apps. > As I said, I don't want to excuse just merely point out that it is not always as clear cut as you might think. We know our painful limits and we are extremely happy for every help we can get from the community. Alex, I'm not trying to pin blame on anyone. I understand the hardships all too well. I'm only interested in finding a solution. I would gladly help myself more but as I mentioned I already maintain a lot of code and I often can't afford to tackle another project. The regressions hurt even more because of that as I need to spend time to find horrible workarounds in my own code. I do plan to engage more though, as the number of regressions affecting me personally is reaching a tipping point. I just need to figure out the logistics. > Some domains are only maintained by the community and I am sure you can understand that nobody can or should ask them to work beyond their dedication either. Yes, and I wouldn't even start this topic if it was about those community driven modules. My complaint is mostly about the older parts, specifically widgets, which I consider core (as the location in the repo would suggest). > There are a few things where bug reporters can help too. Providing information when asked is extremely helpful. This might mean that reporter has to strip down their buggy app to a point that we can run it by ourselves or they even attempt to identify the problem in the code. That's why we have this additional state "Need more Info" in Jira. Sadly, there are over 2k bugs in the system where we asked for more feedback and have not received the required info within the last 6 months. This situation is so bad that we'll soon close those tasks as incomplete. Of course, the reporter can always reopen and provide more info in case the reporter or the assignee forgot about it. But in the greater context this is an expression of us trying to improve by focusing effort. I deal with bug reports all day long so I get that too. There's nothing more annoying than a report along the lines of "something is wrong, fix it" and then radio silence. I always try to provide as much info as I can and attach a simplistic repro code. > Looking from an individual reporters perspective, there are bound to be lucky and unlucky ones. I get that. Let me try to be more constructive then - looking at the proportion of the number of those long standing unresolved issues to the number of bullet points in the release notes by module I'd say a lot of those unlucky ones sit in the widgets area (e.g. 2 minor fixes in 5.11.2 is hardly an adequate pace). Maybe some resources could be shifted there? I know the focus is on the newer ui technologies (I don't want to start the flame on QML) and I know Qt Company maintains the position that widgets are still supported but, to me at least, the facts speak for themselves - widgets are really being penalized - either by lack of maintenance or regressions caused by advancements in those other areas. > P.S. On the positive side, in regular intervals we do a bugfixing week. During such a week the entire RnD org focuses only on bugs. I consider them a fairly successful exercise and as luck will have it, we have one next week That's great to hear. It's a good initiative, but I fear that due to the size of Qt that's simply not enough (as unsympathetic as it may sound, sorry). Also I obviously don't know that but I suspect the focus of these bugfixing weeks is on the new shiny stuff, not older tech like widgets, right? At least I don't see that in release notes volume. Qt is on a pretty steady schedule of releases now. I know this might sound radical but would it be possible to have lets say once in a year full minor (i.e. 5.x) release devoted solely to bug fixing and not (or sparingly) introducing new features? I understand features are the fuel of a project but it looks like each new feature drags a flush of regressions behind it that are rarely rectified. That's simply not sustainable. In Qt 4 I was always looking forward to new releases to discover new features. In Qt 5 it gradually shifted towards grumpily wondering what's gonna break this time. Qt won't stop growing and with its increasing size the amount of maintenance, especially on these older modules,
Re: [Interest] QML: Wrapping an item from outside
Those eample were pure Qml, not C++. For the auto size, you are on the
right track with the childrenRect.
I just don't get your example. but just alias to your Rectangle childrens
or data. If you use a delegate (this is normally used for Component
property that will be instantiate).
if you want dynamic instance,
property Component delegate
Then you will need something like Loader, Repeater, ObjectLoader to create
instance of the Component.
On Mon, 1 Oct 2018 at 09:58, Jason H wrote:
> Hm... All that involves C++. I mean to do it all in QML.
>
> Let me give a better example
>
> //MyAutoSizeRectangle.qml
> Rectangle {
>width: childrenRect.width
>height: childrenRect.height
>radius: Math.min(width, height) / 2
> }
>
> // main.qml
> MyAutoSizeRectangle {
> color:"red"
> Text {
> text: "Danger Will Robinson!"
> color: "white"
> }
> }
>
> or alteratively:
> // main.qml
> MyAutoSizeRectangle {
> color:"red"
> delgate: Text {
> text: "Danger Will Robinson!"
> color: "white"
> }
> }
>
> In this example, I want the MyAutoSizeRectangle instance to apply
> whatever. I am thinking something maybe like a visual item model of size 1?
> But then I have to deal with the view management.
>
>
>
>
> *Sent:* Friday, September 28, 2018 at 2:21 PM
> *From:* "Jérôme Godbout"
> *To:* furkanuzu...@gmail.com
> *Cc:* "Qt Interest" , "Jason H"
> *Subject:* Re: [Interest] QML: Wrapping an item from outside
> Like Furkan said, use the default property alias to chidlren:
>
> MyUI
> {
> default property alias childs: container_.childrens // you can also
> target .data to have non Item objects
>
> PrettyContainer { id: container_ }
> }
>
> On Fri, 28 Sep 2018 at 13:31, Furkan Üzümcü
> wrote:
>
>> I think you are looking for the `default` property.
>>
>> Check out this guide for more information:
>> *https://doc.qt.io/qt-5/qtqml-referenceexamples-default-example.html*
>>
>>
>> Regards,
>> Furkan Üzümcü
>> On Sep 28, 2018, 13:27 -0400, Jason H , wrote:
>>
>> I have PrettyContainer.qml
>>
>> I have an item (Item) I want to put into (on top of) PrettyContainer. My
>> PrettyContainer visually wraps the pretty item, like parent of a child
>> widget
>>
>> MyUI{
>>
>> PrettyContainer {
>>
>> Item {
>> // completely custom 1
>> }
>> }
>> PrettyContainer {
>>
>> Item {
>> // completely custom 2
>> }
>> }
>> }
>>
>>
>> How can I get My PrettyContainer to take the item as like, say, a
>> contentItem? I thought I did this before, but I can't figure out how I did
>> it, and googling s not returning anything relevant.
>>
>> Thanks!
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
> --
>
>
>
>
> RAPPROCHEZ LA DISTANCE
>
> *Jérôme Godbout*
> Senior Software Developer
>
> *p:* +1 (418) 800-1073 ext.:109
>
> *m:* +1 (581) 777-0050
>
> amotus.ca
[Interest] [solved] Re: QML: Wrapping an item from outside [solved]
Ah, nevermind, I went down a rabbit hole of links, and eventually found the section I wanted. Thanks everyone!
FFR:
http://doc.qt.io/qt-5/qtqml-syntax-objectattributes.html#default-properties
Sent: Monday, October 01, 2018 at 9:58 AM
From: "Jason H"
To: "Jérôme Godbout"
Cc: "Qt Interest"
Subject: Re: [Interest] QML: Wrapping an item from outside
Hm... All that involves C++. I mean to do it all in QML.
Let me give a better example
//MyAutoSizeRectangle.qml
Rectangle {
width: childrenRect.width
height: childrenRect.height
radius: Math.min(width, height) / 2
}
// main.qml
MyAutoSizeRectangle {
color:"red"
Text {
text: "Danger Will Robinson!"
color: "white"
}
}
or alteratively:
// main.qml
MyAutoSizeRectangle {
color:"red"
delgate: Text {
text: "Danger Will Robinson!"
color: "white"
}
}
In this example, I want the MyAutoSizeRectangle instance to apply whatever. I am thinking something maybe like a visual item model of size 1? But then I have to deal with the view management.
Sent: Friday, September 28, 2018 at 2:21 PM
From: "Jérôme Godbout"
To: furkanuzu...@gmail.com
Cc: "Qt Interest" , "Jason H"
Subject: Re: [Interest] QML: Wrapping an item from outside
Like Furkan said, use the default property alias to chidlren:
MyUI
{
default property alias childs: container_.childrens // you can also target .data to have non Item objects
PrettyContainer { id: container_ }
}
On Fri, 28 Sep 2018 at 13:31, Furkan Üzümcü wrote:
I think you are looking for the `default` property.
Check out this guide for more information: https://doc.qt.io/qt-5/qtqml-referenceexamples-default-example.html
Regards,
Furkan Üzümcü
On Sep 28, 2018, 13:27 -0400, Jason H , wrote:
I have PrettyContainer.qml
I have an item (Item) I want to put into (on top of) PrettyContainer. My PrettyContainer visually wraps the pretty item, like parent of a child widget
MyUI{
PrettyContainer {
Item {
// completely custom 1
}
}
PrettyContainer {
Item {
// completely custom 2
}
}
}
How can I get My PrettyContainer to take the item as like, say, a contentItem? I thought I did this before, but I can't figure out how I did it, and googling s not returning anything relevant.
Thanks!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
--
RAPPROCHEZ LA DISTANCE
Jérôme Godbout
Senior Software Developer
p: +1 (418) 800-1073 ext.:109
m: +1 (581) 777-0050
amotus.ca
statum-iot.com
___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QML: Wrapping an item from outside
Hm... All that involves C++. I mean to do it all in QML.
Let me give a better example
//MyAutoSizeRectangle.qml
Rectangle {
width: childrenRect.width
height: childrenRect.height
radius: Math.min(width, height) / 2
}
// main.qml
MyAutoSizeRectangle {
color:"red"
Text {
text: "Danger Will Robinson!"
color: "white"
}
}
or alteratively:
// main.qml
MyAutoSizeRectangle {
color:"red"
delgate: Text {
text: "Danger Will Robinson!"
color: "white"
}
}
In this example, I want the MyAutoSizeRectangle instance to apply whatever. I am thinking something maybe like a visual item model of size 1? But then I have to deal with the view management.
Sent: Friday, September 28, 2018 at 2:21 PM
From: "Jérôme Godbout"
To: furkanuzu...@gmail.com
Cc: "Qt Interest" , "Jason H"
Subject: Re: [Interest] QML: Wrapping an item from outside
Like Furkan said, use the default property alias to chidlren:
MyUI
{
default property alias childs: container_.childrens // you can also target .data to have non Item objects
PrettyContainer { id: container_ }
}
On Fri, 28 Sep 2018 at 13:31, Furkan Üzümcü wrote:
I think you are looking for the `default` property.
Check out this guide for more information: https://doc.qt.io/qt-5/qtqml-referenceexamples-default-example.html
Regards,
Furkan Üzümcü
On Sep 28, 2018, 13:27 -0400, Jason H , wrote:
I have PrettyContainer.qml
I have an item (Item) I want to put into (on top of) PrettyContainer. My PrettyContainer visually wraps the pretty item, like parent of a child widget
MyUI{
PrettyContainer {
Item {
// completely custom 1
}
}
PrettyContainer {
Item {
// completely custom 2
}
}
}
How can I get My PrettyContainer to take the item as like, say, a contentItem? I thought I did this before, but I can't figure out how I did it, and googling s not returning anything relevant.
Thanks!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
--
RAPPROCHEZ LA DISTANCE
Jérôme Godbout
Senior Software Developer
p: +1 (418) 800-1073 ext.:109
m: +1 (581) 777-0050
amotus.ca
statum-iot.com
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Priority of bugs
On 9/30/18 5:27 PM, Giuseppe D'Angelo wrote: You stated: a lot of shortcuts get taken and are allowed as long as the test-nothing automated test clears Jenkins. This is a FALSE STATEMENT, no matter if it's Jenkins or Coin or whatever CI suite Qt happens to be using. You're not off the hook. On 09/20/2018 03:27 PM, Krzysztof Kawa wrote: Hi, I really hate to be "that guy" again, but I'd just like to know what's going on. Some time ago I complained about bugs not being resolved for many major releases. I was then told my reports were P2 or lower and I can't expect them to be taken care of. That sucks for me but I can understand to some degree. But now a new release is out and I still have three P1:Critical issues, reported 3 or 4 releases ago, all being regressions btw, and nothing is fixed. There's a next major release around the corner and it doesn't seem to fix these either. In your professional experience, how does this situation happen? In my professional experience, it happens in one of the following ways. 1) Code is not reviewed against a System Architecture Document 2) Integration testing didn't test an existing feature 3) Integration testing failed and a version was released anyway These are all shortcuts. -- Roland Hughes, President Logikal Solutions (630) 205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog http://lesedi.us ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Interest Digest, Vol 85, Issue 1
On 9/30/18 5:27 PM, interest-requ...@qt-project.org wrote: I'm returning there for a few months to participate in a re-evaluation process. They are considering ditching Qt for Electron. Doing side by side development on all platforms to see which works best for them. When we stumble into one of those features we need which doesn't exist on all platforms, there won't be any way I can continue making a case for Qt. Qt is far more superior over Electron in any sense except only one: developer in Qt must be more skilled than common html/css/js developer due to tight links to C++ So, your customer does not choose between "good" and "bad" tech. It's just a question of HR and TTM Actually they are choosing between tech. There is very little development happening. Just creating a browser based/type application which serves up local content without Internet access. Must run on massive number of platforms. Once deployed the content can be changed out at will but the application does not change. The locally running app needs to do things most of today's browsers won't allow. Things Electron claims to provide (not tried yet) -- Roland Hughes, President Logikal Solutions (630) 205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog http://lesedi.us ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Porting Qt to our RTOS
Hi! Forgive me for butting into this off-topic discussion about "true software egnineering" (which is a horrible wording). AFAI understand that discussion is about quality. Well, if you want to know how to develop quality software, you need to look into safety (not security!) industry. People which are responsible for other peoples life and health tend to start *really* caring about quality. So if you want to learn about methods to increase software quality, go checking what safety engineers do. Of course safety is a different and expensive world by its own and you can not copy their methods for conventional software since the effort is too big, but still it shows you which methods are suited to increase quality. You will see that what Roland states is a part of these methods. PS: I have more or less given up reporting Qt bugs and suggestions for years. Judge yourself if this a reasonable and/or desired effect of your way of handling issues or not. I miss Qt 4.0.0 times a lot. It was fun back then. -- Best Regards Bernhard Lindner ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Porting Qt to our RTOS
Hi Guiseppe, > (The topic is still "how to port Qt to another platform".) It is in the nature of discussions, that they might change direction - like it happened with the AGILE side track. > (Yes, I 100% agree that QtQuick could be modularized much further, e.g. > drop its dependency from QtQml altogether, expose C++ APIs for the > QtQuick items, offer ready-made "rich" scene graph items, have clear and > explicit support for more than just OpenGL. A good summary of my point of view - even if the last one was not on my list so far and I would add "being more careful with resources". > But I don't want to start this conversation in this thread, let's have > it in the right places.). You might have access to these "right places", public forums is all what I have. Actually we already made a presentation at the QtCon 2016 ( https:// conf.qtcon.org/en/qtcon/public/events/428.html ) without seeing much of an effect. Showing an implementation is probably my best option to fuel the discussion. If you are trying to improve things from the inside and you are interested in experiences on our journey - don't hesitate to contact me. ciao, Uwe ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
