[Interest] Qt 5.6.0 on iOS - QGeoPositionInfoSource issues

[Dirk Hohndel]

Hi there,

I run an interesting little project that provides an application across quite a 
few different OSs - with a Qt/QWidget UI for Windows, Mac, and various Linux 
flavors, and a QML UI (with currently significantly limited functionality) that 
can be built for Mac and Linux, but that is mainly targeted at Android and iOS. 
Our Android app has been in testing for a while and was recently released and 
QGeoPositioningInfoSource there seems to be doing what I expected it to do, but 
on iOS (our newest platform where we just started beta testing) I'm running 
into some problems:

a) on iPads without GPS (so only WiFi location guestimation), 
supportedPositioningMethods() returns  
QGeoPositionInfoSource::AllPositioningMethods, therefore claiming that there 
are satellite based positioning methods available, even though there clearly 
aren't.

b) regardless of the update interval given via setUpdateInterval() the 
application receives a nearly constant flow of positionUpdated() signals - 
usually more than once a second

c) even though the Info.plist file contains 
NSLocationAlwaysUsageDescription
Explanation why
the position information service stops the moment the application is no longer 
running in the foreground (and resumes once the application is in the 
foreground again) 

Looking at the ObjectiveC APIs for position services on iOS neither of these 
three issues are platform limitation. iOS clearly tells an app whether a 
satellite based position service is available, iOS allows positionUpdates to be 
delayed both by time interval and (that's something I'd love to see in the Qt 
API) by geo-fencing, specifically distance from the last fix. And iOS allows 
applications to continue to receive position updates in the background and when 
the phone is asleep (that's the perfect of the Info.plist key mentioned under 
c).

Any help addressing these issues would be extremely welcome!

Thanks

/D___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Crowdfunding campaign for QtWebEngine support in qutebrowser, a vim-like browser

[Florian Bruhin]

Hi!

(first of all, I hope this kind of thing is okay on this list - I
decided to go for it after I saw some release announcements too.
Please let me know if not, and sorry!)

I'm the main developer of qutebrowser, a keyboard-focused vim-like web
browser built using Qt and Python: http://www.qutebrowser.org/

qutebrowser is currently using QtWebKit - this comes with various
stability, performance and security issues. This is why I want to add
QtWebEngine support to the project.

Since this is a lot more work than I originally hoped when I started
2.5 years ago, I decided to launch a crowdfunding campaign with the
goal to work on this full-time for a few weeks.

You can find the campaign here: http://igg.me/at/qutebrowser

Thanks!

Florian

-- 
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
 I love long mails! | http://email.is-not-s.ms/


signature.asc
Description: Digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Amharic character support?

[Jason H]

Awesome, thanks for the link.

FYI: To use:
main.cpp: 
QFontDatabase::addApplicationFont(":/assets/NotoSansEthiopic-Regular.ttf");
MyText.qml: Text{ family: "Montserrat,Noto Sans Ethiopic" }

> Sent: Thursday, March 24, 2016 at 3:14 PM
> From: "Jesse Jaara" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Amharic character support?
>
> 24.03.2016, 20:44, Jason H kirjoitti:
> > I'm not sure at all. I'm using Monserrat, which is a google
> > font, which works for every language I have except that one.
> > But somehow my browser can display it. I copied the text out
> > of chrome and plopped it in.
> 
> Actually the Montserrat font from google only supports Latin characters. 
> Your system is simply falling back to use another
> for all those languages. You may want to use the Noto Sans family
> of fonts instead, which includes a font for amharic too.
> 
> https://www.google.com/get/noto
> ___
> 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] Amharic character support?

[Jesse Jaara]

24.03.2016, 20:44, Jason H kirjoitti:

I'm not sure at all. I'm using Monserrat, which is a google
font, which works for every language I have except that one.
But somehow my browser can display it. I copied the text out
of chrome and plopped it in.


Actually the Montserrat font from google only supports Latin characters. 
Your system is simply falling back to use another

for all those languages. You may want to use the Noto Sans family
of fonts instead, which includes a font for amharic too.

https://www.google.com/get/noto
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Amharic character support?

[Jason H]

> On quinta-feira, 24 de março de 2016 17:41:30 PDT Jason H wrote:
> > Amharic (Ethiopian) is giving me some trouble. All the other languages are
> > fine. What do I need to do get Amharic characters showing? They are
> > rendered as boxes. 
> 
> How are you sure you have a font with those characters? Are you sure you're 
> using that font?

I'm not sure at all. I'm using Monserrat, which is a google font, which works 
for every language I have except that one. But somehow my browser can display 
it. I copied the text out of chrome and plopped it in.

property var nativeLanguages: {
'english' : 'english',  // ok
'amharic' : 'አማርኛ', // not ok, except in chrome
'arabic' : 'عربي عربى', // ok
'burmese' : 'မြန်မာစကာ',// ok
'french' : 'français',// ok
'kinyarwanda' : 'kinyarwanda',// ok
'mandarin' : '普通话',// ok
'portugese' : 'português',// ok
'spanish' : 'español',// ok
'swahili' : 'swahili'// ok
}
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Nye]

> I've fixed it with the GameReference class.

It seems an overkill to use a number of QObject instances to track a simple
integer, but I'm glad it's working at least.
Sorry I couldn't be of more help, but no one had been kind of enough to
pitch in and put me out of my misery.  :D

Kind regards.

On Thu, Mar 24, 2016 at 7:35 PM, Curtis Mitch  wrote:

> I've fixed it with the GameReference class.
>
>
> --
> *From:* Nye 
> *Sent:* Thursday, 24 March 2016 18:28
>
> *To:* Curtis Mitch
> *Cc:* interest@qt-project.org
> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
> deferred deletion
>
> > I've explained the problems with referencing the game object in the bug
> report. :)
>
> That's why I moved player.destroy(); out of the if (state == "invalid") block.
> But my last comment applies: unless there's a way to track explicitly the
> objects' lifetimes in QML I don't see how you can fix this.
>
> On Thu, Mar 24, 2016 at 7:21 PM, Curtis Mitch <
> mitch.cur...@theqtcompany.com> wrote:
>
>> I've explained the problems with referencing the game object in the bug
>> report. :)
>>
>>
>> --
>> *From:* Nye 
>> *Sent:* Thursday, 24 March 2016 17:45
>>
>> *To:* Curtis Mitch
>> *Cc:* interest@qt-project.org
>> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
>> deferred deletion
>>
>> > The "loadedComponents" thing is more or less the same as the GameScope
>> thing (I ended up calling it GameReference), except you need to remember to
>> increment the count yourself, whereas with GameScope, it does it
>> automatically.
>>
>> Mostly yes, except that this is tied to the loader, not to the loaded
>> item.
>>
>> > The problem with the code you posted is as I mentioned earlier: Loader
>> never immediately deletes its items, so the code would still reference
>> the game object when it shouldn't.
>>
>> Code referencing the game object should be perfectly fine until all the
>> loaders have finished unloading their respective components (which I assume
>> is signaled by loader.status == Loader.Null), then you know that you can
>> destroy() whatever you wish as destroying it will happen (even if loaders
>> queue their destructions) after all the loaded components have been
>> destroyed. Isn't this what you wanted in the first place, or am I
>> misunderstanding?
>>
>> On Thu, Mar 24, 2016 at 1:53 PM, Curtis Mitch <
>> mitch.cur...@theqtcompany.com> wrote:
>>
>>> The "loadedComponents" thing is more or less the same as the GameScope
>>> thing (I ended up calling it GameReference), except you need to remember to
>>> increment the count yourself, whereas with GameScope, it does it
>>> automatically.
>>>
>>>
>>> The problem with the code you posted is as I mentioned earlier: Loader
>>> never immediately deletes its items, so the code would still reference
>>> the game object when it shouldn't.
>>>
>>>
>>> --
>>> *From:* Nye 
>>> *Sent:* Thursday, 24 March 2016 11:25
>>>
>>> *To:* Curtis Mitch
>>> *Cc:* interest@qt-project.org
>>> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs
>>> after deferred deletion
>>>
>>> Okay,
>>> It might sound stupid, but why not notify the game from your loaders?
>>> Supposedly setting the source of the loader to NULL will unload the
>>> component (at least that's what the documentation says).
>>> Something like this (please bear with my tortured QML knowledge):
>>>
>>>
>>> Item {
>>> id: theGame
>>>
>>> property bool isReady: false
>>> property int loadedComponents: 0
>>>
>>> onStateChanged: {
>>> if (state == "invalid") {
>>> print("game.isReady about to change to false...")
>>> isReady = false;
>>> print("... game.isReady changed to " + isReady);
>>> }  else if (state == "running") {
>>> player = Qt.createQmlObject("import QtQuick 2.0; Item {
>>> property color color: 'black' }", window);
>>>
>>> print("game.isReady about to change to true...")
>>> isReady = true;
>>> print("... game.isReady changed to true")
>>> }
>>> else if (state == "finished") {
>>> // ... Everything was cleaned now ... supposedly
>>> }
>>> }
>>>
>>> onLoadedComponentsChanged: {
>>> if (state == "invalid" && loadedComponents == 0)  {
>>> player.destroy();
>>> player = null;
>>>
>>> state = "finished";
>>> print("... game.state changed to finished; nothing should
>>> reference properties of game now");
>>> }
>>> }
>>>
>>> property Item player
>>> }
>>>
>>> Loader {
>>> id: loader
>>>
>>> Connections {
>>> target: theGame
>>> onIsReadyChanged: {
>>> if (theGame.isReady) {
>>> loader.setSource("qrc:/LoaderItem.qml", { "game":
>>> theGame });
>>> theGame.loadedComponents++;
>>> } else 

[Interest] Qml Loader initial property setter

[Jérôme Godbout]

Hi,

I was wondering if I am the only one who found the initial property of a
source based Loader Item a bit annoying. inline sourceComponent with
Component {} declaration are well ok on the other hand. I'm explaining
myself, when using a loader you have 2 choice to set the initial binding on
created item:

1- On item changed set the binding

*Loader*
*{*
*  source: externalObj.getSrc() // return something like "myItem.qml"*
*  onItemChanged:*
*  {*
*if(!item) return;*
*item.myprop = Qt.binding(function(){ return myExternalProperty; })*
*  }*
*}*

2- use the setSource() function instead of the source directly

*Loader*
*{*
*  property url myDummySrc: externalObj.getSrc()*
*  onMyDummySrcChanged:*
*  {*
* setSource(myDummySrc, { 'myprop': Qt.binding(function(){ return
myExternalProperty; }) });*
*  }*
*}*

This is rather annoying and ugly. Number 1 is also having the problem where
*myItem.qml* must be able to handle *myprop *to have a default value or
being empty without output a lots of console error. Number 2 work well and
is the solution I find myself writing often. I was wondering if a Loader
that support a dictionary of initial property when source changed would be
nice:

*Loader*
*{*
*  source: externalObj.getSrc()*
*  initialProperties: { 'myprop': Qt.binding(function(){ return
myExternalProperty; })  }*
*}*

What do you think?
Jerome
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Curtis Mitch]

I've fixed it with the GameReference class.



From: Nye 
Sent: Thursday, 24 March 2016 18:28
To: Curtis Mitch
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

> I've explained the problems with referencing the game object in the bug 
> report. :)

That's why I moved player.destroy(); out of the if (state == "invalid") block. 
But my last comment applies: unless there's a way to track explicitly the 
objects' lifetimes in QML I don't see how you can fix this.

On Thu, Mar 24, 2016 at 7:21 PM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:

I've explained the problems with referencing the game object in the bug report. 
:)



From: Nye mailto:kshegu...@gmail.com>>
Sent: Thursday, 24 March 2016 17:45

To: Curtis Mitch
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

> The "loadedComponents" thing is more or less the same as the GameScope thing 
> (I ended up calling it GameReference), except you need to remember to 
> increment the count yourself, whereas with GameScope, it does it 
> automatically.

Mostly yes, except that this is tied to the loader, not to the loaded item.

> The problem with the code you posted is as I mentioned earlier: Loader never 
> immediately deletes its items, so the code would still reference the game 
> object when it shouldn't.

Code referencing the game object should be perfectly fine until all the loaders 
have finished unloading their respective components (which I assume is signaled 
by loader.status == Loader.Null), then you know that you can destroy() whatever 
you wish as destroying it will happen (even if loaders queue their 
destructions) after all the loaded components have been destroyed. Isn't this 
what you wanted in the first place, or am I misunderstanding?

On Thu, Mar 24, 2016 at 1:53 PM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:

The "loadedComponents" thing is more or less the same as the GameScope thing (I 
ended up calling it GameReference), except you need to remember to increment 
the count yourself, whereas with GameScope, it does it automatically.


The problem with the code you posted is as I mentioned earlier: Loader never 
immediately deletes its items, so the code would still reference the game 
object when it shouldn't.



From: Nye mailto:kshegu...@gmail.com>>
Sent: Thursday, 24 March 2016 11:25

To: Curtis Mitch
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Okay,
It might sound stupid, but why not notify the game from your loaders? 
Supposedly setting the source of the loader to NULL will unload the component 
(at least that's what the documentation says).
Something like this (please bear with my tortured QML knowledge):


Item {
id: theGame

property bool isReady: false
property int loadedComponents: 0

onStateChanged: {
if (state == "invalid") {
print("game.isReady about to change to false...")
isReady = false;
print("... game.isReady changed to " + isReady);
}  else if (state == "running") {
player = Qt.createQmlObject("import QtQuick 2.0; Item { property 
color color: 'black' }", window);

print("game.isReady about to change to true...")
isReady = true;
print("... game.isReady changed to true")
}
else if (state == "finished") {
// ... Everything was cleaned now ... supposedly
}
}

onLoadedComponentsChanged: {
if (state == "invalid" && loadedComponents == 0)  {
player.destroy();
player = null;

state = "finished";
print("... game.state changed to finished; nothing should reference 
properties of game now");
}
}

property Item player
}

Loader {
id: loader

Connections {
target: theGame
onIsReadyChanged: {
if (theGame.isReady) {
loader.setSource("qrc:/LoaderItem.qml", { "game": theGame });
theGame.loadedComponents++;
} else {
loader.source = null;
}
}
}

onStatusChanged:  {
if (loader.status == Loader.Null)  {
theGame.loadedComponents--;
}
}
}

On Thu, Mar 24, 2016 at 10:48 AM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:

The problem with doing this is that you'd still need to identify the Loaders 
that are relevant to (have references to) the game, so you'd end up with more 
or less the same amount of extra QML code (a line or two). It also ties it to 
Loaders, but the same problem exists with the destroy() JavaScript function, 
for example.

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Nye]

> I've explained the problems with referencing the game object in the bug
report. :)

That's why I moved player.destroy(); out of the if (state == "invalid") block.
But my last comment applies: unless there's a way to track explicitly the
objects' lifetimes in QML I don't see how you can fix this.

On Thu, Mar 24, 2016 at 7:21 PM, Curtis Mitch  wrote:

> I've explained the problems with referencing the game object in the bug
> report. :)
>
>
> --
> *From:* Nye 
> *Sent:* Thursday, 24 March 2016 17:45
>
> *To:* Curtis Mitch
> *Cc:* interest@qt-project.org
> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
> deferred deletion
>
> > The "loadedComponents" thing is more or less the same as the GameScope
> thing (I ended up calling it GameReference), except you need to remember to
> increment the count yourself, whereas with GameScope, it does it
> automatically.
>
> Mostly yes, except that this is tied to the loader, not to the loaded item.
>
> > The problem with the code you posted is as I mentioned earlier: Loader
> never immediately deletes its items, so the code would still reference
> the game object when it shouldn't.
>
> Code referencing the game object should be perfectly fine until all the
> loaders have finished unloading their respective components (which I assume
> is signaled by loader.status == Loader.Null), then you know that you can
> destroy() whatever you wish as destroying it will happen (even if loaders
> queue their destructions) after all the loaded components have been
> destroyed. Isn't this what you wanted in the first place, or am I
> misunderstanding?
>
> On Thu, Mar 24, 2016 at 1:53 PM, Curtis Mitch <
> mitch.cur...@theqtcompany.com> wrote:
>
>> The "loadedComponents" thing is more or less the same as the GameScope
>> thing (I ended up calling it GameReference), except you need to remember to
>> increment the count yourself, whereas with GameScope, it does it
>> automatically.
>>
>>
>> The problem with the code you posted is as I mentioned earlier: Loader
>> never immediately deletes its items, so the code would still reference
>> the game object when it shouldn't.
>>
>>
>> --
>> *From:* Nye 
>> *Sent:* Thursday, 24 March 2016 11:25
>>
>> *To:* Curtis Mitch
>> *Cc:* interest@qt-project.org
>> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
>> deferred deletion
>>
>> Okay,
>> It might sound stupid, but why not notify the game from your loaders?
>> Supposedly setting the source of the loader to NULL will unload the
>> component (at least that's what the documentation says).
>> Something like this (please bear with my tortured QML knowledge):
>>
>>
>> Item {
>> id: theGame
>>
>> property bool isReady: false
>> property int loadedComponents: 0
>>
>> onStateChanged: {
>> if (state == "invalid") {
>> print("game.isReady about to change to false...")
>> isReady = false;
>> print("... game.isReady changed to " + isReady);
>> }  else if (state == "running") {
>> player = Qt.createQmlObject("import QtQuick 2.0; Item {
>> property color color: 'black' }", window);
>>
>> print("game.isReady about to change to true...")
>> isReady = true;
>> print("... game.isReady changed to true")
>> }
>> else if (state == "finished") {
>> // ... Everything was cleaned now ... supposedly
>> }
>> }
>>
>> onLoadedComponentsChanged: {
>> if (state == "invalid" && loadedComponents == 0)  {
>> player.destroy();
>> player = null;
>>
>> state = "finished";
>> print("... game.state changed to finished; nothing should
>> reference properties of game now");
>> }
>> }
>>
>> property Item player
>> }
>>
>> Loader {
>> id: loader
>>
>> Connections {
>> target: theGame
>> onIsReadyChanged: {
>> if (theGame.isReady) {
>> loader.setSource("qrc:/LoaderItem.qml", { "game": theGame
>> });
>> theGame.loadedComponents++;
>> } else {
>> loader.source = null;
>> }
>> }
>> }
>>
>> onStatusChanged:  {
>> if (loader.status == Loader.Null)  {
>> theGame.loadedComponents--;
>> }
>> }
>> }
>>
>> On Thu, Mar 24, 2016 at 10:48 AM, Curtis Mitch <
>> mitch.cur...@theqtcompany.com> wrote:
>>
>>> The problem with doing this is that you'd still need to identify the
>>> Loaders that are relevant to (have references to) the game, so you'd end up
>>> with more or less the same amount of extra QML code (a line or two). It
>>> also ties it to Loaders, but the same problem exists with the destroy()
>>> JavaScript function, for example.
>>>
>>>
>>> --
>>> *From:* Nye 
>>> *Sent:* Thursday, 24 March 2016 01:41
>>> *To:* Curtis Mitch
>>>
>>> *

Re: [Interest] Amharic character support?

[Thiago Macieira]

On quinta-feira, 24 de março de 2016 17:41:30 PDT Jason H wrote:
> Amharic (Ethiopian) is giving me some trouble. All the other languages are
> fine. What do I need to do get Amharic characters showing? They are
> rendered as boxes. 

How are you sure you have a font with those characters? Are you sure you're 
using that font?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Curtis Mitch]

I've explained the problems with referencing the game object in the bug report. 
:)



From: Nye 
Sent: Thursday, 24 March 2016 17:45
To: Curtis Mitch
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

> The "loadedComponents" thing is more or less the same as the GameScope thing 
> (I ended up calling it GameReference), except you need to remember to 
> increment the count yourself, whereas with GameScope, it does it 
> automatically.

Mostly yes, except that this is tied to the loader, not to the loaded item.

> The problem with the code you posted is as I mentioned earlier: Loader never 
> immediately deletes its items, so the code would still reference the game 
> object when it shouldn't.

Code referencing the game object should be perfectly fine until all the loaders 
have finished unloading their respective components (which I assume is signaled 
by loader.status == Loader.Null), then you know that you can destroy() whatever 
you wish as destroying it will happen (even if loaders queue their 
destructions) after all the loaded components have been destroyed. Isn't this 
what you wanted in the first place, or am I misunderstanding?

On Thu, Mar 24, 2016 at 1:53 PM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:

The "loadedComponents" thing is more or less the same as the GameScope thing (I 
ended up calling it GameReference), except you need to remember to increment 
the count yourself, whereas with GameScope, it does it automatically.


The problem with the code you posted is as I mentioned earlier: Loader never 
immediately deletes its items, so the code would still reference the game 
object when it shouldn't.



From: Nye mailto:kshegu...@gmail.com>>
Sent: Thursday, 24 March 2016 11:25

To: Curtis Mitch
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Okay,
It might sound stupid, but why not notify the game from your loaders? 
Supposedly setting the source of the loader to NULL will unload the component 
(at least that's what the documentation says).
Something like this (please bear with my tortured QML knowledge):


Item {
id: theGame

property bool isReady: false
property int loadedComponents: 0

onStateChanged: {
if (state == "invalid") {
print("game.isReady about to change to false...")
isReady = false;
print("... game.isReady changed to " + isReady);
}  else if (state == "running") {
player = Qt.createQmlObject("import QtQuick 2.0; Item { property 
color color: 'black' }", window);

print("game.isReady about to change to true...")
isReady = true;
print("... game.isReady changed to true")
}
else if (state == "finished") {
// ... Everything was cleaned now ... supposedly
}
}

onLoadedComponentsChanged: {
if (state == "invalid" && loadedComponents == 0)  {
player.destroy();
player = null;

state = "finished";
print("... game.state changed to finished; nothing should reference 
properties of game now");
}
}

property Item player
}

Loader {
id: loader

Connections {
target: theGame
onIsReadyChanged: {
if (theGame.isReady) {
loader.setSource("qrc:/LoaderItem.qml", { "game": theGame });
theGame.loadedComponents++;
} else {
loader.source = null;
}
}
}

onStatusChanged:  {
if (loader.status == Loader.Null)  {
theGame.loadedComponents--;
}
}
}

On Thu, Mar 24, 2016 at 10:48 AM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:

The problem with doing this is that you'd still need to identify the Loaders 
that are relevant to (have references to) the game, so you'd end up with more 
or less the same amount of extra QML code (a line or two). It also ties it to 
Loaders, but the same problem exists with the destroy() JavaScript function, 
for example.



From: Nye mailto:kshegu...@gmail.com>>
Sent: Thursday, 24 March 2016 01:41
To: Curtis Mitch

Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Hello,
> At one stage I thought about having a C++ object that could be created in QML 
> and would somehow keep count of references to the game object. For example, 
> each Loader whose source component has access to the game object would 
> somehow register itself with the object, and the game wouldn’t start quitting 
> until all references were gone. As long as the C++ doesn’t know about the UI, 
> I think it could work quite well.

Unfortunately

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Nye]

Skimming through the source however, I'm not quite sure I reasoned
correctly in my previous mail, as it seems the Loader will just change its
status without tracking its children's lifetimes. So basically, Loader.Null
is set immediately when it is made inactive. Sadly, I have neither more
suggestions nor ideas how to fix this. With C++ you have the
QObject::destroyed signal to subscribe to, but I have no idea whether QML
exposes it (it's not documented in any case) or if would be of much help
(as this is already achieved in a similar fashion by your GameScope
approach).

Good luck!

On Thu, Mar 24, 2016 at 6:45 PM, Nye  wrote:

> > The "loadedComponents" thing is more or less the same as the GameScope
> thing (I ended up calling it GameReference), except you need to remember to
> increment the count yourself, whereas with GameScope, it does it
> automatically.
>
> Mostly yes, except that this is tied to the loader, not to the loaded item.
>
> > The problem with the code you posted is as I mentioned earlier: Loader
> never immediately deletes its items, so the code would still reference
> the game object when it shouldn't.
>
> Code referencing the game object should be perfectly fine until all the
> loaders have finished unloading their respective components (which I assume
> is signaled by loader.status == Loader.Null), then you know that you can
> destroy() whatever you wish as destroying it will happen (even if loaders
> queue their destructions) after all the loaded components have been
> destroyed. Isn't this what you wanted in the first place, or am I
> misunderstanding?
>
> On Thu, Mar 24, 2016 at 1:53 PM, Curtis Mitch <
> mitch.cur...@theqtcompany.com> wrote:
>
>> The "loadedComponents" thing is more or less the same as the GameScope
>> thing (I ended up calling it GameReference), except you need to remember to
>> increment the count yourself, whereas with GameScope, it does it
>> automatically.
>>
>>
>> The problem with the code you posted is as I mentioned earlier: Loader
>> never immediately deletes its items, so the code would still reference
>> the game object when it shouldn't.
>>
>>
>> --
>> *From:* Nye 
>> *Sent:* Thursday, 24 March 2016 11:25
>>
>> *To:* Curtis Mitch
>> *Cc:* interest@qt-project.org
>> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
>> deferred deletion
>>
>> Okay,
>> It might sound stupid, but why not notify the game from your loaders?
>> Supposedly setting the source of the loader to NULL will unload the
>> component (at least that's what the documentation says).
>> Something like this (please bear with my tortured QML knowledge):
>>
>>
>> Item {
>> id: theGame
>>
>> property bool isReady: false
>> property int loadedComponents: 0
>>
>> onStateChanged: {
>> if (state == "invalid") {
>> print("game.isReady about to change to false...")
>> isReady = false;
>> print("... game.isReady changed to " + isReady);
>> }  else if (state == "running") {
>> player = Qt.createQmlObject("import QtQuick 2.0; Item {
>> property color color: 'black' }", window);
>>
>> print("game.isReady about to change to true...")
>> isReady = true;
>> print("... game.isReady changed to true")
>> }
>> else if (state == "finished") {
>> // ... Everything was cleaned now ... supposedly
>> }
>> }
>>
>> onLoadedComponentsChanged: {
>> if (state == "invalid" && loadedComponents == 0)  {
>> player.destroy();
>> player = null;
>>
>> state = "finished";
>> print("... game.state changed to finished; nothing should
>> reference properties of game now");
>> }
>> }
>>
>> property Item player
>> }
>>
>> Loader {
>> id: loader
>>
>> Connections {
>> target: theGame
>> onIsReadyChanged: {
>> if (theGame.isReady) {
>> loader.setSource("qrc:/LoaderItem.qml", { "game": theGame
>> });
>> theGame.loadedComponents++;
>> } else {
>> loader.source = null;
>> }
>> }
>> }
>>
>> onStatusChanged:  {
>> if (loader.status == Loader.Null)  {
>> theGame.loadedComponents--;
>> }
>> }
>> }
>>
>> On Thu, Mar 24, 2016 at 10:48 AM, Curtis Mitch <
>> mitch.cur...@theqtcompany.com> wrote:
>>
>>> The problem with doing this is that you'd still need to identify the
>>> Loaders that are relevant to (have references to) the game, so you'd end up
>>> with more or less the same amount of extra QML code (a line or two). It
>>> also ties it to Loaders, but the same problem exists with the destroy()
>>> JavaScript function, for example.
>>>
>>>
>>> --
>>> *From:* Nye 
>>> *Sent:* Thursday, 24 March 2016 01:41
>>> *To:* Curtis Mitch
>>>
>>> *Cc:* interest@qt-project.org
>>> *Subject:* Re: [I

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Nye]

> The "loadedComponents" thing is more or less the same as the GameScope
thing (I ended up calling it GameReference), except you need to remember to
increment the count yourself, whereas with GameScope, it does it
automatically.

Mostly yes, except that this is tied to the loader, not to the loaded item.

> The problem with the code you posted is as I mentioned earlier: Loader
never immediately deletes its items, so the code would still reference
the game object when it shouldn't.

Code referencing the game object should be perfectly fine until all the
loaders have finished unloading their respective components (which I assume
is signaled by loader.status == Loader.Null), then you know that you can
destroy() whatever you wish as destroying it will happen (even if loaders
queue their destructions) after all the loaded components have been
destroyed. Isn't this what you wanted in the first place, or am I
misunderstanding?

On Thu, Mar 24, 2016 at 1:53 PM, Curtis Mitch  wrote:

> The "loadedComponents" thing is more or less the same as the GameScope
> thing (I ended up calling it GameReference), except you need to remember to
> increment the count yourself, whereas with GameScope, it does it
> automatically.
>
>
> The problem with the code you posted is as I mentioned earlier: Loader
> never immediately deletes its items, so the code would still reference
> the game object when it shouldn't.
>
>
> --
> *From:* Nye 
> *Sent:* Thursday, 24 March 2016 11:25
>
> *To:* Curtis Mitch
> *Cc:* interest@qt-project.org
> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
> deferred deletion
>
> Okay,
> It might sound stupid, but why not notify the game from your loaders?
> Supposedly setting the source of the loader to NULL will unload the
> component (at least that's what the documentation says).
> Something like this (please bear with my tortured QML knowledge):
>
>
> Item {
> id: theGame
>
> property bool isReady: false
> property int loadedComponents: 0
>
> onStateChanged: {
> if (state == "invalid") {
> print("game.isReady about to change to false...")
> isReady = false;
> print("... game.isReady changed to " + isReady);
> }  else if (state == "running") {
> player = Qt.createQmlObject("import QtQuick 2.0; Item {
> property color color: 'black' }", window);
>
> print("game.isReady about to change to true...")
> isReady = true;
> print("... game.isReady changed to true")
> }
> else if (state == "finished") {
> // ... Everything was cleaned now ... supposedly
> }
> }
>
> onLoadedComponentsChanged: {
> if (state == "invalid" && loadedComponents == 0)  {
> player.destroy();
> player = null;
>
> state = "finished";
> print("... game.state changed to finished; nothing should
> reference properties of game now");
> }
> }
>
> property Item player
> }
>
> Loader {
> id: loader
>
> Connections {
> target: theGame
> onIsReadyChanged: {
> if (theGame.isReady) {
> loader.setSource("qrc:/LoaderItem.qml", { "game": theGame
> });
> theGame.loadedComponents++;
> } else {
> loader.source = null;
> }
> }
> }
>
> onStatusChanged:  {
> if (loader.status == Loader.Null)  {
> theGame.loadedComponents--;
> }
> }
> }
>
> On Thu, Mar 24, 2016 at 10:48 AM, Curtis Mitch <
> mitch.cur...@theqtcompany.com> wrote:
>
>> The problem with doing this is that you'd still need to identify the
>> Loaders that are relevant to (have references to) the game, so you'd end up
>> with more or less the same amount of extra QML code (a line or two). It
>> also ties it to Loaders, but the same problem exists with the destroy()
>> JavaScript function, for example.
>>
>>
>> --
>> *From:* Nye 
>> *Sent:* Thursday, 24 March 2016 01:41
>> *To:* Curtis Mitch
>>
>> *Cc:* interest@qt-project.org
>> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
>> deferred deletion
>>
>> Hello,
>> > At one stage I thought about having a C++ object that could be created
>> in QML and would somehow keep count of references to the game object. For
>> example, each Loader whose source component has access to the game object
>> would somehow register itself with the object, and the game wouldn’t start
>> quitting until all references were gone. As long as the C++ doesn’t know
>> about the UI, I think it could work quite well.
>>
>> Unfortunately my QML knowledge is quite rudimentary, however I believe
>> (correct me if I'm wrong) each component is a `QObject` instance and is
>> parented to the parent component and so on until you reach the root
>> context. So one thing that comes to mind is to "spy" (by inst

[Interest] Amharic character support?

[Jason H]

Amharic (Ethiopian) is giving me some trouble. All the other languages are 
fine. What do I need to do get Amharic characters showing? They are rendered as 
boxes.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Canvas keeping artifacts

[Jérôme Godbout]

reverse engineering of methods on object, we have some debug tools to list
methods and properties on object at run time, kinda what KDAB Gamma Ray is
doing https://www.kdab.com/gammaray/
So I try it out, I remembered having a hard time with the same problems.
The rest are probably left over from previous try and what we are expecting
a Web Canvas would react to.

On Thu, Mar 24, 2016 at 9:49 AM, Jason H  wrote:

> By the way, reset() is not a W3C function, and it's also not in the QML
> Canvas documentation.
>
> I'm wondering how you found it?
>
>
>
> *Sent:* Thursday, March 24, 2016 at 9:42 AM
> *From:* "Jason H" 
> *To:* "Jérôme Godbout" 
>
> *Cc:* "interest@qt-project.org Interest" 
> *Subject:* Re: [Interest] Canvas keeping artifacts
> ctx.reset(); fixes it.
>
> Again, I think you have meaningless statements.
> ctx.beginPath(); // It's not a path
> ctx.fillStyle = 'rgba(0,0,0,0)'; // it's not using fillStyle
> ctx.clearRect(0,0,width,height); // this works
> ctx.fill(); // there is no closed path to fill
>
> *Sent:* Wednesday, March 23, 2016 at 6:21 PM
> *From:* "Jérôme Godbout" 
> *To:* "Jason H" 
> *Cc:* "interest@qt-project.org Interest" 
> *Subject:* Re: [Interest] Canvas keeping artifacts
> Canvas
> {
> id: component
> //...
> renderStrategy: Canvas.Immediate
> renderTarget: Canvas.FramebufferObject
>
> onWidthChanged: requestPaint()
> onHeightChanged: requestPaint()
> onPaint: paintHandler()
>
> function paintHandler()
> {
> var ctx = getContext('2d');
> ctx.reset();
> // clear with transparent
> ctx.beginPath();
> ctx.fillStyle = 'rgba(0,0,0,0)';
> ctx.clearRect(0,0,width,height);
> ctx.fill();
> // Set general style
> ...
> // Call draw functions here
> ...
> }
> }
>
> At a few overhead near, this is what I do, the thing is clear, I guess my
> ctx.reset() is the missing key here, I had problems too with this clear
> thing with Qml Canvas where Html canvas where working perfectly fine with
> the same code.
>
> My guess is that the Widgets try to redraw as little as possible somehow,
> not sure if a replacement to the requestPaint() or a function that will:
> function myRequestPaint()
> {
>   markDirty(Qt.rect(0,0,width,height));
>   requestPaint();
> }
>
> onWidthChanged: myRequestPaint()
> onHeightChanged: myRequestPaint()
>
> Hope this help you out, let me know if the makeDirty() change anything, I
> may change my code for it too.
>
> Jerome
>
> On Wed, Mar 23, 2016 at 5:26 PM, Jason H  wrote:
>>
>> Thanks for the tip, but a few things:
>> 1. I don't think clearRect uses fillStyle
>> 2. I don't think clearRect needs a fill, as "clear" implies both color
>> and fill op.
>> http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_canvas_clearrect
>>
>>
>> I had played with that, including your code, no luck.
>> It looks like the Black Sabbath - Paraoid album cover.
>>
>>
>> *Sent:* Wednesday, March 23, 2016 at 5:11 PM
>> *From:* "Jérôme Godbout" 
>> *To:* "Jason H" 
>> *Cc:* "interest@qt-project.org Interest" 
>> *Subject:* Re: [Interest] Canvas keeping artifacts
>> You may want to clear fill with blank transparency:
>>
>> ctx.fillStyle = 'rgba(0,0,0,0)';
>> ctx.clearRect(0,0,width,height);
>> ctx.fill();
>>
>> for me it did the trick.
>>
>> On Wed, Mar 23, 2016 at 4:54 PM, Jason H  wrote:
>>>
>>> I have a very simple pause button:
>>> Canvas {
>>> id: pauseCanvas
>>> anchors.fill: parent
>>> onWidthChanged: requestPaint()
>>> onHeightChanged: requestPaint()
>>> onPaint: {
>>> var ctx = getContext('2d');
>>> ctx.save()
>>> ctx.clearRect(0,0, width,height)
>>> ctx.fillStyle = color;
>>> ctx.rect(0.125*width, 0.05*height, 0.25*width,
>>> 0.90*height);
>>> ctx.fill();
>>> ctx.rect(0.625*width, 0.05*height, 0.25*width,
>>> 0.90*height);
>>> ctx.fill();
>>> ctx.restore();
>>> }
>>> }
>>>
>>> The problem is when I resize the window (which in turn resizes the
>>> canvas), I get artifacts of previous draws. If the window is made larger
>>> (corner drag or maximize) I can see the smaller original rectangles. And
>>> vice-versa.
>>>
>>> How can I get Canvas to play nice?
>>>
>>>
>>> ___
>>> 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
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Canvas keeping artifacts

[Jason H]

By the way, reset() is not a W3C function, and it's also not in the QML Canvas documentation.

 

I'm wondering how you found it?

 

 

 

Sent: Thursday, March 24, 2016 at 9:42 AM
From: "Jason H" 
To: "Jérôme Godbout" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Canvas keeping artifacts




ctx.reset(); fixes it.

 


Again, I think you have meaningless statements.


ctx.beginPath(); // It's not a path

ctx.fillStyle = 'rgba(0,0,0,0)'; // it's not using fillStyle

ctx.clearRect(0,0,width,height); // this works

ctx.fill(); // there is no closed path to fill

 



Sent: Wednesday, March 23, 2016 at 6:21 PM
From: "Jérôme Godbout" 
To: "Jason H" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Canvas keeping artifacts


Canvas
{

        id: component

        //...


        renderStrategy: Canvas.Immediate

        renderTarget: Canvas.FramebufferObject


 

        onWidthChanged: requestPaint()
        onHeightChanged: requestPaint()


        onPaint: paintHandler()

 


        function paintHandler()

{

var ctx = getContext('2d');

ctx.reset();

// clear with transparent

ctx.beginPath();

ctx.fillStyle = 'rgba(0,0,0,0)';

ctx.clearRect(0,0,width,height);

ctx.fill();

// Set general style

                ...

// Call draw functions here

...

}


}


 

At a few overhead near, this is what I do, the thing is clear, I guess my ctx.reset() is the missing key here, I had problems too with this clear thing with Qml Canvas where Html canvas where working perfectly fine with the same code.

 

My guess is that the Widgets try to redraw as little as possible somehow, not sure if a replacement to the requestPaint() or a function that will:

function myRequestPaint()

{

      markDirty(Qt.rect(0,0,width,height));

      requestPaint();

}

 


onWidthChanged: myRequestPaint()
onHeightChanged: myRequestPaint()

 

Hope this help you out, let me know if the makeDirty() change anything, I may change my code for it too.

 

Jerome


 
On Wed, Mar 23, 2016 at 5:26 PM, Jason H  wrote:





Thanks for the tip, but a few things:

1. I don't think clearRect uses fillStyle

2. I don't think clearRect needs a fill, as "clear" implies both color and fill op. http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_canvas_clearrect

 

 

I had played with that, including your code, no luck.

It looks like the Black Sabbath - Paraoid album cover. 

 

 

Sent: Wednesday, March 23, 2016 at 5:11 PM
From: "Jérôme Godbout" 
To: "Jason H" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Canvas keeping artifacts




You may want to clear fill with blank transparency:

 

ctx.fillStyle = 'rgba(0,0,0,0)';

ctx.clearRect(0,0,width,height);

ctx.fill();


 

for me it did the trick.


 
On Wed, Mar 23, 2016 at 4:54 PM, Jason H  wrote:

I have a very simple pause button:
        Canvas {
                id: pauseCanvas
                anchors.fill: parent
                onWidthChanged: requestPaint()
                onHeightChanged: requestPaint()
                onPaint: {
                        var ctx = getContext('2d');
                        ctx.save()
                        ctx.clearRect(0,0, width,height)
                        ctx.fillStyle = color;
                        ctx.rect(0.125*width, 0.05*height, 0.25*width, 0.90*height);
                        ctx.fill();
                        ctx.rect(0.625*width, 0.05*height, 0.25*width, 0.90*height);
                        ctx.fill();
                        ctx.restore();
                }
        }

The problem is when I resize the window (which in turn resizes the canvas), I get artifacts of previous draws. If the window is made larger (corner drag or maximize) I can see the smaller original rectangles. And vice-versa.

How can I get Canvas to play nice?


___
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



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Canvas keeping artifacts

[Jason H]

ctx.reset(); fixes it.

 


Again, I think you have meaningless statements.


ctx.beginPath(); // It's not a path

ctx.fillStyle = 'rgba(0,0,0,0)'; // it's not using fillStyle

ctx.clearRect(0,0,width,height); // this works

ctx.fill(); // there is no closed path to fill

 



Sent: Wednesday, March 23, 2016 at 6:21 PM
From: "Jérôme Godbout" 
To: "Jason H" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Canvas keeping artifacts


Canvas
{

        id: component

        //...


        renderStrategy: Canvas.Immediate

        renderTarget: Canvas.FramebufferObject


 

        onWidthChanged: requestPaint()
        onHeightChanged: requestPaint()


        onPaint: paintHandler()

 


        function paintHandler()

{

var ctx = getContext('2d');

ctx.reset();

// clear with transparent

ctx.beginPath();

ctx.fillStyle = 'rgba(0,0,0,0)';

ctx.clearRect(0,0,width,height);

ctx.fill();

// Set general style

                ...

// Call draw functions here

...

}


}


 

At a few overhead near, this is what I do, the thing is clear, I guess my ctx.reset() is the missing key here, I had problems too with this clear thing with Qml Canvas where Html canvas where working perfectly fine with the same code.

 

My guess is that the Widgets try to redraw as little as possible somehow, not sure if a replacement to the requestPaint() or a function that will:

function myRequestPaint()

{

      markDirty(Qt.rect(0,0,width,height));

      requestPaint();

}

 


onWidthChanged: myRequestPaint()
onHeightChanged: myRequestPaint()

 

Hope this help you out, let me know if the makeDirty() change anything, I may change my code for it too.

 

Jerome


 
On Wed, Mar 23, 2016 at 5:26 PM, Jason H  wrote:





Thanks for the tip, but a few things:

1. I don't think clearRect uses fillStyle

2. I don't think clearRect needs a fill, as "clear" implies both color and fill op. http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_canvas_clearrect

 

 

I had played with that, including your code, no luck.

It looks like the Black Sabbath - Paraoid album cover. 

 

 

Sent: Wednesday, March 23, 2016 at 5:11 PM
From: "Jérôme Godbout" 
To: "Jason H" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Canvas keeping artifacts




You may want to clear fill with blank transparency:

 

ctx.fillStyle = 'rgba(0,0,0,0)';

ctx.clearRect(0,0,width,height);

ctx.fill();


 

for me it did the trick.


 
On Wed, Mar 23, 2016 at 4:54 PM, Jason H  wrote:

I have a very simple pause button:
        Canvas {
                id: pauseCanvas
                anchors.fill: parent
                onWidthChanged: requestPaint()
                onHeightChanged: requestPaint()
                onPaint: {
                        var ctx = getContext('2d');
                        ctx.save()
                        ctx.clearRect(0,0, width,height)
                        ctx.fillStyle = color;
                        ctx.rect(0.125*width, 0.05*height, 0.25*width, 0.90*height);
                        ctx.fill();
                        ctx.rect(0.625*width, 0.05*height, 0.25*width, 0.90*height);
                        ctx.fill();
                        ctx.restore();
                }
        }

The problem is when I resize the window (which in turn resizes the canvas), I get artifacts of previous draws. If the window is made larger (corner drag or maximize) I can see the smaller original rectangles. And vice-versa.

How can I get Canvas to play nice?


___
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] [Quick] GridView inside the Layout

[Sina Dogru]

> "The implicit size of the GroupBox
>  is calculated
> based on the size of its content. If you want to anchor items inside the
> group box, you must specify an explicit width and height on the GroupBox
>  itself."
>
> [1] http://doc.qt.io/qt-5/qml-qtquick-controls-groupbox.html#details
>

Ah, then inner `ColumnLayout` was actually cause this error message not the
`GridView`. Thank you, that solves my problem.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Curtis Mitch]

The "loadedComponents" thing is more or less the same as the GameScope thing (I 
ended up calling it GameReference), except you need to remember to increment 
the count yourself, whereas with GameScope, it does it automatically.


The problem with the code you posted is as I mentioned earlier: Loader never 
immediately deletes its items, so the code would still reference the game 
object when it shouldn't.



From: Nye 
Sent: Thursday, 24 March 2016 11:25
To: Curtis Mitch
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Okay,
It might sound stupid, but why not notify the game from your loaders? 
Supposedly setting the source of the loader to NULL will unload the component 
(at least that's what the documentation says).
Something like this (please bear with my tortured QML knowledge):


Item {
id: theGame

property bool isReady: false
property int loadedComponents: 0

onStateChanged: {
if (state == "invalid") {
print("game.isReady about to change to false...")
isReady = false;
print("... game.isReady changed to " + isReady);
}  else if (state == "running") {
player = Qt.createQmlObject("import QtQuick 2.0; Item { property 
color color: 'black' }", window);

print("game.isReady about to change to true...")
isReady = true;
print("... game.isReady changed to true")
}
else if (state == "finished") {
// ... Everything was cleaned now ... supposedly
}
}

onLoadedComponentsChanged: {
if (state == "invalid" && loadedComponents == 0)  {
player.destroy();
player = null;

state = "finished";
print("... game.state changed to finished; nothing should reference 
properties of game now");
}
}

property Item player
}

Loader {
id: loader

Connections {
target: theGame
onIsReadyChanged: {
if (theGame.isReady) {
loader.setSource("qrc:/LoaderItem.qml", { "game": theGame });
theGame.loadedComponents++;
} else {
loader.source = null;
}
}
}

onStatusChanged:  {
if (loader.status == Loader.Null)  {
theGame.loadedComponents--;
}
}
}

On Thu, Mar 24, 2016 at 10:48 AM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:

The problem with doing this is that you'd still need to identify the Loaders 
that are relevant to (have references to) the game, so you'd end up with more 
or less the same amount of extra QML code (a line or two). It also ties it to 
Loaders, but the same problem exists with the destroy() JavaScript function, 
for example.



From: Nye mailto:kshegu...@gmail.com>>
Sent: Thursday, 24 March 2016 01:41
To: Curtis Mitch

Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Hello,
> At one stage I thought about having a C++ object that could be created in QML 
> and would somehow keep count of references to the game object. For example, 
> each Loader whose source component has access to the game object would 
> somehow register itself with the object, and the game wouldn’t start quitting 
> until all references were gone. As long as the C++ doesn’t know about the UI, 
> I think it could work quite well.

Unfortunately my QML knowledge is quite rudimentary, however I believe (correct 
me if I'm wrong) each component is a `QObject` instance and is parented to the 
parent component and so on until you reach the root context. So one thing that 
comes to mind is to "spy" (by installing an event filter) on the root context 
for when children are added or removed (QEvent::ChildAdded & 
QEvent::ChildRemoved) and if the children are Loaders then count them up. 
Respectively when they're destroyed you decrease the count and when it goes to 
zero you can unload/clean up. This approach would (hopefully) lift the need to 
do this:

GameScope {
   game: root.game
}

Kind regards.

On Wed, Mar 23, 2016 at 10:41 AM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:
Hi.

That does help, thanks. It means that I’d really need to use an arbitrarily 
long timer, or find the “proper” solution.

At one stage I thought about having a C++ object that could be created in QML 
and would somehow keep count of references to the game object. For example, 
each Loader whose source component has access to the game object would somehow 
register itself with the object, and the game wouldn’t start quitting until all 
references were gone. As long as the C++ doesn’t know about the UI, I think it 
could work quite well.

Something like this:

Loader {
// ... contains GameView
}

// GameView.qml

Item {
id: root
prop

[Interest] Calendar widget style sheet

[Roland Hughes]

All,

I have a touch screen project with a 600 pixel width and 1024 height. On 
one of the pages we need a calendar widget but we need it to look good 
and be "finger sized". I poked around quite a bit and found a starter 
stylesheet on this thread: 
http://www.qtcentre.org/threads/30478-How-To-Change-Style-Sheet-for-QCalendarWidget


It looks great...but... doesn't quite fit. What I cannot find for the 
life of me is the stylesheet setting to adjust the column width. 
Squeezing the font size down to almost unreadable will shrink them some, 
but still leaves wide margins in the columns. Does anyone know what 
attribute I need to tweak to adjust the column sizes for the days?


Thanks,

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Nye]

"Supposedly setting the source of the loader to NULL" to be read as "Supposedly
setting the source of the loader to an empty string"

On Thu, Mar 24, 2016 at 12:25 PM, Nye  wrote:

> Okay,
> It might sound stupid, but why not notify the game from your loaders?
> Supposedly setting the source of the loader to NULL will unload the
> component (at least that's what the documentation says).
> Something like this (please bear with my tortured QML knowledge):
>
>
> Item {
> id: theGame
>
> property bool isReady: false
> property int loadedComponents: 0
>
> onStateChanged: {
> if (state == "invalid") {
> print("game.isReady about to change to false...")
> isReady = false;
> print("... game.isReady changed to " + isReady);
> }  else if (state == "running") {
> player = Qt.createQmlObject("import QtQuick 2.0; Item {
> property color color: 'black' }", window);
>
> print("game.isReady about to change to true...")
> isReady = true;
> print("... game.isReady changed to true")
> }
> else if (state == "finished") {
> // ... Everything was cleaned now ... supposedly
> }
> }
>
> onLoadedComponentsChanged: {
> if (state == "invalid" && loadedComponents == 0)  {
> player.destroy();
> player = null;
>
> state = "finished";
> print("... game.state changed to finished; nothing should
> reference properties of game now");
> }
> }
>
> property Item player
> }
>
> Loader {
> id: loader
>
> Connections {
> target: theGame
> onIsReadyChanged: {
> if (theGame.isReady) {
> loader.setSource("qrc:/LoaderItem.qml", { "game": theGame
> });
> theGame.loadedComponents++;
> } else {
> loader.source = null;
> }
> }
> }
>
> onStatusChanged:  {
> if (loader.status == Loader.Null)  {
> theGame.loadedComponents--;
> }
> }
> }
>
> On Thu, Mar 24, 2016 at 10:48 AM, Curtis Mitch <
> mitch.cur...@theqtcompany.com> wrote:
>
>> The problem with doing this is that you'd still need to identify the
>> Loaders that are relevant to (have references to) the game, so you'd end up
>> with more or less the same amount of extra QML code (a line or two). It
>> also ties it to Loaders, but the same problem exists with the destroy()
>> JavaScript function, for example.
>>
>>
>> --
>> *From:* Nye 
>> *Sent:* Thursday, 24 March 2016 01:41
>> *To:* Curtis Mitch
>>
>> *Cc:* interest@qt-project.org
>> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
>> deferred deletion
>>
>> Hello,
>> > At one stage I thought about having a C++ object that could be created
>> in QML and would somehow keep count of references to the game object. For
>> example, each Loader whose source component has access to the game object
>> would somehow register itself with the object, and the game wouldn’t start
>> quitting until all references were gone. As long as the C++ doesn’t know
>> about the UI, I think it could work quite well.
>>
>> Unfortunately my QML knowledge is quite rudimentary, however I believe
>> (correct me if I'm wrong) each component is a `QObject` instance and is
>> parented to the parent component and so on until you reach the root
>> context. So one thing that comes to mind is to "spy" (by installing an
>> event filter) on the root context for when children are added or removed
>> (QEvent::ChildAdded & QEvent::ChildRemoved) and if the children are Loaders
>> then count them up. Respectively when they're destroyed you decrease the
>> count and when it goes to zero you can unload/clean up. This approach would
>> (hopefully) lift the need to do this:
>>
>> GameScope {
>>
>>game: root.game
>>
>> }
>>
>>
>> Kind regards.
>>
>> On Wed, Mar 23, 2016 at 10:41 AM, Curtis Mitch <
>> mitch.cur...@theqtcompany.com> wrote:
>>
>>> Hi.
>>>
>>>
>>>
>>> That does help, thanks. It means that I’d really need to use an
>>> arbitrarily long timer, or find the “proper” solution.
>>>
>>>
>>>
>>> At one stage I thought about having a C++ object that could be created
>>> in QML and would somehow keep count of references to the game object. For
>>> example, each Loader whose source component has access to the game object
>>> would somehow register itself with the object, and the game wouldn’t start
>>> quitting until all references were gone. As long as the C++ doesn’t know
>>> about the UI, I think it could work quite well.
>>>
>>>
>>>
>>> Something like this:
>>>
>>>
>>>
>>> Loader {
>>>
>>> // ... contains GameView
>>>
>>> }
>>>
>>>
>>>
>>> // GameView.qml
>>>
>>>
>>>
>>> Item {
>>>
>>> id: root
>>>
>>> property alias game
>>>
>>>
>>>
>>> GameScope {
>>>
>>> game: root.game
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> // GameScope.cpp
>>>
>

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Nye]

Okay,
It might sound stupid, but why not notify the game from your loaders?
Supposedly setting the source of the loader to NULL will unload the
component (at least that's what the documentation says).
Something like this (please bear with my tortured QML knowledge):


Item {
id: theGame

property bool isReady: false
property int loadedComponents: 0

onStateChanged: {
if (state == "invalid") {
print("game.isReady about to change to false...")
isReady = false;
print("... game.isReady changed to " + isReady);
}  else if (state == "running") {
player = Qt.createQmlObject("import QtQuick 2.0; Item {
property color color: 'black' }", window);

print("game.isReady about to change to true...")
isReady = true;
print("... game.isReady changed to true")
}
else if (state == "finished") {
// ... Everything was cleaned now ... supposedly
}
}

onLoadedComponentsChanged: {
if (state == "invalid" && loadedComponents == 0)  {
player.destroy();
player = null;

state = "finished";
print("... game.state changed to finished; nothing should
reference properties of game now");
}
}

property Item player
}

Loader {
id: loader

Connections {
target: theGame
onIsReadyChanged: {
if (theGame.isReady) {
loader.setSource("qrc:/LoaderItem.qml", { "game": theGame
});
theGame.loadedComponents++;
} else {
loader.source = null;
}
}
}

onStatusChanged:  {
if (loader.status == Loader.Null)  {
theGame.loadedComponents--;
}
}
}

On Thu, Mar 24, 2016 at 10:48 AM, Curtis Mitch <
mitch.cur...@theqtcompany.com> wrote:

> The problem with doing this is that you'd still need to identify the
> Loaders that are relevant to (have references to) the game, so you'd end up
> with more or less the same amount of extra QML code (a line or two). It
> also ties it to Loaders, but the same problem exists with the destroy()
> JavaScript function, for example.
>
>
> --
> *From:* Nye 
> *Sent:* Thursday, 24 March 2016 01:41
> *To:* Curtis Mitch
>
> *Cc:* interest@qt-project.org
> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
> deferred deletion
>
> Hello,
> > At one stage I thought about having a C++ object that could be created
> in QML and would somehow keep count of references to the game object. For
> example, each Loader whose source component has access to the game object
> would somehow register itself with the object, and the game wouldn’t start
> quitting until all references were gone. As long as the C++ doesn’t know
> about the UI, I think it could work quite well.
>
> Unfortunately my QML knowledge is quite rudimentary, however I believe
> (correct me if I'm wrong) each component is a `QObject` instance and is
> parented to the parent component and so on until you reach the root
> context. So one thing that comes to mind is to "spy" (by installing an
> event filter) on the root context for when children are added or removed
> (QEvent::ChildAdded & QEvent::ChildRemoved) and if the children are Loaders
> then count them up. Respectively when they're destroyed you decrease the
> count and when it goes to zero you can unload/clean up. This approach would
> (hopefully) lift the need to do this:
>
> GameScope {
>
>game: root.game
>
> }
>
>
> Kind regards.
>
> On Wed, Mar 23, 2016 at 10:41 AM, Curtis Mitch <
> mitch.cur...@theqtcompany.com> wrote:
>
>> Hi.
>>
>>
>>
>> That does help, thanks. It means that I’d really need to use an
>> arbitrarily long timer, or find the “proper” solution.
>>
>>
>>
>> At one stage I thought about having a C++ object that could be created in
>> QML and would somehow keep count of references to the game object. For
>> example, each Loader whose source component has access to the game object
>> would somehow register itself with the object, and the game wouldn’t start
>> quitting until all references were gone. As long as the C++ doesn’t know
>> about the UI, I think it could work quite well.
>>
>>
>>
>> Something like this:
>>
>>
>>
>> Loader {
>>
>> // ... contains GameView
>>
>> }
>>
>>
>>
>> // GameView.qml
>>
>>
>>
>> Item {
>>
>> id: root
>>
>> property alias game
>>
>>
>>
>> GameScope {
>>
>> game: root.game
>>
>> }
>>
>> }
>>
>>
>>
>> // GameScope.cpp
>>
>>
>>
>> GameScope::setGame(Game *game)
>>
>> {
>>
>> if (game == mGame)
>>
>> return;
>>
>>
>>
>> if (game)
>>
>> game->increaseReferenceCount();
>>
>> else
>>
>> game->decreaseReferenceCount();
>>
>>
>>
>> mGame = game;
>>
>> }
>>
>>
>>
>> GameScope::~GameScope()
>>
>> {
>>
>> if (game)
>>
>> game->decreaseReferenceCount();
>>
>> }
>>
>>
>>
>>
>>
>> Each 

Re: [Interest] [Quick] GridView inside the Layout

[Curtis Mitch]

"The implicit size of the 
GroupBox is 
calculated based on the size of its content. If you want to anchor items inside 
the group box, you must specify an explicit width and height on the 
GroupBox itself."

[1] http://doc.qt.io/qt-5/qml-qtquick-controls-groupbox.html#details


From: Interest  
on behalf of Sina Dogru 
Sent: Thursday, 24 March 2016 08:39
To: interest@qt-project.org
Subject: [Interest] [Quick] GridView inside the Layout

I guess my assumption about qt-quick Layouts might not be right. Consider a 
window where there are some properties, but they all inside a `ColumnLayout` so 
that `ScrollView` would be able to use on it. Also there is some 
QtQuick.Controls inside them. I guess code would be more expository.

import QtQuick 2.6
import QtQuick.Window 2.2
import QtQuick.Controls 1.4
import QtQuick.Layouts 1.1

Window {
visible: true
height: 500
width: 500

ColumnLayout {
anchors.fill: parent

GroupBox {
Layout.fillWidth: true
ColumnLayout {
anchors.fill: parent
GridView {
cellWidth: 100
cellHeight: 20
Layout.fillWidth: true

model: [ "1", "2", "3", "4", "5", "6", "7" ]

delegate: Rectangle {
width: GridView.view.cellWidth
height: GridView.view.cellHeight
color: "red"
Text {
anchors.fill: parent
verticalAlignment: Text.AlignVCenter
horizontalAlignment: Text.AlignHCenter
text: modelData
}
}
}
}
}
}
}

When I run this code, qmlengine gives an error about the implicitWidth and 
implicitHeight,


qrc:/main.qml:14:9: QML GroupBox: Binding loop detected for property 
"implicitWidth"

qrc:/main.qml:14:9: QML GroupBox: Binding loop detected for property 
"implicitWidth"

qrc:/main.qml:14:9: QML GroupBox: Binding loop detected for property 
"implicitHeight"

qrc:/main.qml:14:9: QML GroupBox: Binding loop detected for property 
"implicitHeight"


I assume using `GridView` inside `ColumnLayout` causes that. Because when use a 
`Rectangle` instead of a `GridView` engine does not give any errors.

So can someone please point where am I doing wrong?

Thank you,
Sina

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Curtis Mitch]

The problem with doing this is that you'd still need to identify the Loaders 
that are relevant to (have references to) the game, so you'd end up with more 
or less the same amount of extra QML code (a line or two). It also ties it to 
Loaders, but the same problem exists with the destroy() JavaScript function, 
for example.



From: Nye 
Sent: Thursday, 24 March 2016 01:41
To: Curtis Mitch
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Hello,
> At one stage I thought about having a C++ object that could be created in QML 
> and would somehow keep count of references to the game object. For example, 
> each Loader whose source component has access to the game object would 
> somehow register itself with the object, and the game wouldn’t start quitting 
> until all references were gone. As long as the C++ doesn’t know about the UI, 
> I think it could work quite well.

Unfortunately my QML knowledge is quite rudimentary, however I believe (correct 
me if I'm wrong) each component is a `QObject` instance and is parented to the 
parent component and so on until you reach the root context. So one thing that 
comes to mind is to "spy" (by installing an event filter) on the root context 
for when children are added or removed (QEvent::ChildAdded & 
QEvent::ChildRemoved) and if the children are Loaders then count them up. 
Respectively when they're destroyed you decrease the count and when it goes to 
zero you can unload/clean up. This approach would (hopefully) lift the need to 
do this:

GameScope {
   game: root.game
}

Kind regards.

On Wed, Mar 23, 2016 at 10:41 AM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:
Hi.

That does help, thanks. It means that I’d really need to use an arbitrarily 
long timer, or find the “proper” solution.

At one stage I thought about having a C++ object that could be created in QML 
and would somehow keep count of references to the game object. For example, 
each Loader whose source component has access to the game object would somehow 
register itself with the object, and the game wouldn’t start quitting until all 
references were gone. As long as the C++ doesn’t know about the UI, I think it 
could work quite well.

Something like this:

Loader {
// ... contains GameView
}

// GameView.qml

Item {
id: root
property alias game

GameScope {
game: root.game
}
}

// GameScope.cpp

GameScope::setGame(Game *game)
{
if (game == mGame)
return;

if (game)
game->increaseReferenceCount();
else
game->decreaseReferenceCount();

mGame = game;
}

GameScope::~GameScope()
{
if (game)
game->decreaseReferenceCount();
}


Each event loop after a quit has been requested, Game could check the reference 
count and begin the actual quitting if it’s 0.

It still feels like it shouldn’t be necessary, but at least there’s no 
guesswork involved.

From: Nye [mailto:kshegu...@gmail.com]
Sent: Tuesday, 22 March 2016 10:33 PM
To: Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>>
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Hello,
I don't work with QML, but I'm pretty sure the events are processed in the 
order of their appearance in the event queue. So if you have a `deleteLater` 
call (i.e. you have a QEvent::DeferredDelete, which is scheduled through the 
event loop) any queued call to a slot (i.e. QEvent::MetaCall) that was made 
before the deletion request should be happening before the actual deletion. So, 
if you're emitting signals from a single thread, their respective slots would 
be called in the order in which the signals had happened.

Now, with multiple threads it's a bit tricky, since there's the chance that two 
threads will be trying to post a deferred function invocation at the same time 
(hence the event queue is protected by a mutex). However that mutex can't 
guarantee in what order the events will be posted, or rather no one can.

> My only thought is to use a zero-second single-shot timer. The question is: 
> is this guaranteed to happen *after* deferred deletion for a given iteration 
> of an event loop?

This posts a timer event on the queue, so you can achieve the same with 
QMetaObject::invokeMethod(receiverObject, "method", Qt::QueuedConnection), and 
the same "restrictions" apply as mentioned above.

I hope this is of help.
Kind regards.

On Tue, Mar 22, 2016 at 7:50 PM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:

I recently discovered [1] that Loader defers deletion of items via 
deleteLater(). Up until that point, I had been treating certain operations in 
my program as synchronous (as I haven't introduced threads yet). Now that I 
can't safely assume that UI items will be instantly destroyed, I have to 
convert these operations int

[Interest] [Quick] GridView inside the Layout

[Sina Dogru]

I guess my assumption about qt-quick Layouts might not be right. Consider a
window where there are some properties, but they all inside a
`ColumnLayout` so that `ScrollView` would be able to use on it. Also there
is some QtQuick.Controls inside them. I guess code would be more expository.

import QtQuick 2.6
import QtQuick.Window 2.2
import QtQuick.Controls 1.4
import QtQuick.Layouts 1.1

Window {
visible: true
height: 500
width: 500

ColumnLayout {
anchors.fill: parent

GroupBox {
Layout.fillWidth: true
ColumnLayout {
anchors.fill: parent
GridView {
cellWidth: 100
cellHeight: 20
Layout.fillWidth: true

model: [ "1", "2", "3", "4", "5", "6", "7" ]

delegate: Rectangle {
width: GridView.view.cellWidth
height: GridView.view.cellHeight
color: "red"
Text {
anchors.fill: parent
verticalAlignment: Text.AlignVCenter
horizontalAlignment: Text.AlignHCenter
text: modelData
}
}
}
}
}
}
}

When I run this code, qmlengine gives an error about the implicitWidth and
implicitHeight,

qrc:/main.qml:14:9: QML GroupBox: Binding loop detected for property
"implicitWidth"

qrc:/main.qml:14:9: QML GroupBox: Binding loop detected for property
"implicitWidth"

qrc:/main.qml:14:9: QML GroupBox: Binding loop detected for property
"implicitHeight"

qrc:/main.qml:14:9: QML GroupBox: Binding loop detected for property
"implicitHeight"


I assume using `GridView` inside `ColumnLayout` causes that. Because when
use a `Rectangle` instead of a `GridView` engine does not give any errors.

So can someone please point where am I doing wrong?

Thank you,
Sina
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest