# App Launching in tk-desktop

**URL:** <https://community.shotgridsoftware.com/t/app-launching-in-tk-desktop/11629>\
**Category:** Pipeline Integrations\
**Created:** [February 22, 2021, 9:48am UTC](https://community.shotgridsoftware.com/t/app-launching-in-tk-desktop/11629 "2021-02-22T09:48:04Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Will](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/will/32/3855_2.png) [@Will](https://community.shotgridsoftware.com/u/Will)\
**Post date:** [February 22, 2021, 9:48am UTC](https://community.shotgridsoftware.com/t/app-launching-in-tk-desktop/11629/1 "2021-02-22T09:48:04Z")

</div>

I’m noticing an odd discrepancy between the way tk-multi-pythonconsole launches in tk-desktop and the way our custom apps do. When launched, tk-multi-pythonconsole does not stay on top of other windows and gets its own icon on the Windows taskbar. Other apps remain above all other windows and do not get an icon on the taskbar. This second behaviour is what I’d expect–the app is being parented to the tk-desktop window and treated as a dialog–but I’d like to be able to replicate the behaviour of tk-multi-pythonconsole. Digging through the code, I can’t actually see where it’s being treated differently. It’s calling `create_panel` which is falling back to `create_dialog`. The console itself is just a subclass of `QWidget`.

I’m certain I’m missing something obvious. Does anyone have any idea what that is?

---

<div class="post-metadata">

**Author:** ![Will](https://sea1.discourse-cdn.com/shotgunsoftware/user_avatar/community.shotgridsoftware.com/will/32/3855_2.png) [@Will](https://community.shotgridsoftware.com/u/Will)\
**Post date:** [March 9, 2021, 10:17am UTC](https://community.shotgridsoftware.com/t/app-launching-in-tk-desktop/11629/2 "2021-03-09T10:17:09Z")

</div>

If anyone is encountering a similar issue to the above, I sorted it out.

I had it backwards. In fact, the `tk-multi-pythonconsole` behaviour is the standard behaviour. My problem was that our custom app had a splash screen. `tk-desktop` has no `_get_dialog_parent` method and so is falling back to the default engine behaviour, which is to return the currently active window. _Usually_, for `tk-desktop`, this returns `None` and you get the standard, unparented dialog behaviour. If you have a splash screen, it returns that and so the dialog ends up parented to its own splash screen, which is…not good. I’m overriding `tk-desktop` anyway so it isn’t a big deal for me to add a `_get_dialog_parent` method that just returns `None` explicitly.

It might be worth considering adding something similar to the default `tk-desktop` implementation. The current behaviour works most of the time but has some funny edge cases.