WARNING: QApplication was not created in the main() thread.

[David Skinner]

2014/04/02 22:58:13 qcoreapplication.cpp:416: WARNING: QApplication was not created in the main() thread.

So I am playing with QML for the first time, trying to learn how to use it, and I sometimes get this runtime warning. Does not happen all of the time.

Should I be worried? How do I make it go away?

[Gustavo Niemeyer]

Are you running anything from the qml package before qml.Init, perhaps
on init functions or in spawned goroutines?

> --
> You received this message because you are subscribed to the Google Groups
> "go-qml" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-qml+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

gustavo @ http://niemeyer.net

[David Skinner]

My code is dead simple right now. InitQml is the first line in main. I do have some other rather complex init functions but they do not touch the QML stuff.

Note that main is in a different package, if that might be the problem.

Also I have been using go run for testing my program.

Final detail. I cannot seem to duplicate the error.! Maybe its cosmic rays?

I am having a lot of fun with QML, it looks like a really great front end for go.

// qml.go

package senet

import (

"gopkg.in/v0/qml"

"log"

"os"

)

// initQml runs the dialogs.

func InitQml() error {

qml.Init(nil)

engine := qml.NewEngine()

engine.On("quit", func() { os.Exit(0) })

component, err := engine.LoadFile("../../qml/SenetWindow/SenetWindow.qml")

if err != nil {

log.Println("Error loading file.")

return err

}

window := component.CreateWindow(nil)

window.Show()

window.Wait()

return nil

}

[Gustavo Niemeyer]

On Thu, Apr 3, 2014 at 10:16 PM, David Skinner <skinne...@gmail.com> wrote:
> My code is dead simple right now. InitQml is the first line in main. I do
> have some other rather complex init functions but they do not touch the QML
> stuff.
> Note that main is in a different package, if that might be the problem.
> Also I have been using go run for testing my program.

All of that should be okay.

> Final detail. I cannot seem to duplicate the error.! Maybe its cosmic rays?

If you do see it again, or find a way to reproduce, please drop me a
message. As some insight into the problem, the message from Qt is a
bit of a lie.. the "main" thread is whatever asks about the current
thread id first. That said, the qml package should in theory be safe
no matter what you do, because qml.Init "unlocks" the rest of the
functionality, and before unlocking it creates the QApplication in a
known thread.

So, that error message must come from an edge case I'd be happy to learn about.

> I am having a lot of fun with QML, it looks like a really great front end
> for go.

I'm glad to hear you're having fun with it. Do you intend to submit
something for the contest that is running until late in the month? If
you're working on a personal toy, that'd be welcome as an entry.


gustavo @ http://niemeyer.net

[David Skinner]

I just watched your video and learned about the contest. I am using QML at the front end for a 3d video game written in go. QML menus to select single player or dual player and to display keymap and game rules. The game itself is playable but has no animation at present, things just move rather abruptly. I have to finish the AI for the computer player, and a friend will be doing some improvement on the graphics. The game may not be finished by the contest deadline but I would like to submit it as a how qml helped me with my project sort of entry. I can release the qml code and the go code that implements the qml but not the entire game, I can also supply a video of the game. If this is okay for the contests, I just need a link to the details.

[Gustavo Niemeyer]

On Thu, Apr 3, 2014 at 10:48 PM, David Skinner <skinne...@gmail.com> wrote:
> I just watched your video and learned about the contest. I am using QML at
> the front end for a 3d video game written in go. QML menus to select single
> player or dual player and to display keymap and game rules. The game itself
> is playable but has no animation at present, things just move rather
> abruptly. I have to finish the AI for the computer player, and a friend will

Ah, nice, that looks promising.

Maybe you've already seen it, but if you're already making things
logically move around, it should be fairly easy to plug in QML logic
to smooth out the animations for you in a declarative fashion. This
should introduce the idea:

http://qt-project.org/doc/qt-5/qtquick-usecase-animations.html

> be doing some improvement on the graphics. The game may not be finished by
> the contest deadline but I would like to submit it as a how qml helped me
> with my project sort of entry. I can release the qml code and the go code
> that implements the qml but not the entire game, I can also supply a video
> of the game. If this is okay for the contests, I just need a link to the
> details.

Yes, please submit what you can and we'll be glad to have a look:

http://blog.labix.org/2014/03/13/go-qml-contest


gustavo @ http://niemeyer.net

[David Marceau]

It isn't error however. It's just a warning. On the desktop or any
multicore system with standard GNU/Linux on it, you don't have to worry
about this. You don't have to worry about this on any recent Windows
OS/Mac OS X either.

For deliberate one-thread mission-critical high-reliability stuff, it
would need to be deliberately assigned before compilation into the main
thread & cpu, but you would have to guarantee the functions all return
within some specific amount of time. The workaround is the classic
collaborative processing call QApplication::processEvents(). You call
it in longer to process functions and especially within some loops with
lots of data processing involved.

That isn't your case, is it? If it is, then you can get specific
documentation to fix/mitigate the warning from your specific hardware
vendor's compiler. Qt also has QObject::moveToThread() and this can
support deliberately assigning a thread to a specific cpu/thread resource.