Do summons underneath other windows in KDE

[Jonas Thorell]

I don't know if this is specific to people running gnome-do outside of Gnome but here goes.

I am running gnome-do in KDE 4, and has used KDE systemsettings to attach a keyboard shortcut to bring up the gnome-do interface. That works great, but the problem is that if a window happen to cover the space where the interface should be I don't see it. In other words, the gnome-do window is not brought "on top" which IMO it should.

[Jason Smith (jassmith)]

I am not sure yet, but I am willing to bet KDE4 is to blame here... the hint is properly set

[Jonas Thorell (jthorell)]

I wouldn't be surprised if that's the reason. Or to be more specific: I wonder if it isn't due to the transparency bug that somehow got introduced in KDE 4.0.2. (it wasn't there in 4.0.1.).

It would be interesting if someone has tried it using earlier versions (4.0.1. *and* 3.5.9.) to see if it can be reproduced.

[Adam Porter (alphapapa)]

This does indeed occur in KDE 3.5.9. Katapult, on the other hand, works fine.

[Jonas Thorell (jthorell)]

@Adam,

Ah, okay. Scratch the idea that it is KDE4 that is causing the problem then. It is a more generic KDE problem. While I'm not a developer at all, I would guess that the souce to Katapult (even if probably written in another language) could give a hint to why it's not working. Or even the OSD of Amarok for that matter.

[David Siegel (djsiegel-deactivatedaccount)]

I don't think we will find the answer in Katapult's source -- this is
probably a Gtk vs Qt thing. The way we get Do to steal focus and rise to the
top of the screen is very hacked, and we should probably talk to some Gtk
people about a more stable solution that may work better on KDE.

[Nate Loudon (killerah)]

I just wanted to say that I'm experiencing this bug as well. It's a crying shame because I'm enjoying KDE ever since 4.1 beta came out, but my favorite GTK app doesn't work quite right for it. It's weird though because sometimes Gnome Do shows up on top at first, but then once it stops showing up on top it always shows up on the bottom for the rest of the session. Maybe it has to do with using GTK apps? I dunno. Hopefully it gets resolved soon enough.

[David Siegel (djsiegel-deactivatedaccount)]

Or maybe it's Qt windows that are behaving badly?

[Nate Loudon (killerah)]

I figured it out! In KDE 4 go to System Settings>Window Behavior and create a new window specific setting. Change "Window class" to "exact match" and type in "Do". Now go to the workarounds tab and set "Focus Stealing Prevention" to "Force" and "None", then change "Window type" to "Force" and "Splash Screen". Hit OK and Apply and you should be good to go. It got Gnome Do working perfectly for me. Good luck!

[David Siegel (djsiegel-deactivatedaccount)]

Can you please post this on the wiki and/or Launchpad answers?
http://do.davebsd.com/wiki

[Nate Loudon (killerah)]

I posted the answer here https://answers.launchpad.net/do/+question/27658 but I'm not sure what to do with the wiki. Where do I post it on there? I've never posted anything on a wiki before. If I knew where to post it I'd go all out and take screenshots and everything to make it as simple as possible.

[David Siegel (djsiegel-deactivatedaccount)]

Do you have a blog? You could just blog it for now and we could add it to
the wiki later.

[Nate Loudon (killerah)]

Oh sorry, no I don't have a blog.

Nate

On Sat, Jul 5, 2008 at 12:14 AM, David Siegel <email address hidden> wrote:

> Do you have a blog? You could just blog it for now and we could add it to
> the wiki later.
>
> --
> Interface ends up behind open windows
> https://bugs.launchpad.net/bugs/204405
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Jason Smith (jassmith)]

It's not our fault, its focus stealing prevention

[Adam Porter (alphapapa)]

Respectfully, what happened to:

"I don't think we will find the answer in Katapult's source -- this is
probably a Gtk vs Qt thing. The way we get Do to steal focus and rise to the
top of the screen is very hacked, and we should probably talk to some Gtk
people about a more stable solution that may work better on KDE."

? If other apps, like Katapult, can properly get focus from KWin, why can't Do be modified to also work with KWin? Even if it needs to use a different method for KWin, it wouldn't be hard to detect which window manager was running.

[nebcanuck (nebcanuck)]

I'm not sure if this should be filed as a separate bug, or if this is relating to KDE, but here goes:

I installed KDE under Ubuntu the other day, to test it out and see if it was any nicer than the last time I tried KDE4. I noticed this behaviour under KDE, but didn't think much of it since I was just fiddling. After a short while, I decided to stick with Gnome, and uninstalled KDE.

However, since then, this same behaviour has arisen in Gnome! I'm not sure if it's a result of the KDE crossover, or if it's because of a new Compiz bug. I do seem to recall that there was also an update to Compiz pretty recently, so it could be related to that instead.

Just tried switching to Metacity, and it works just fine. So it could definitely be Compiz-related. Unless other people experienced this same result from KDE? I'm considering trying to re-install KDE and apply the fix mentioned in this bug report to see if that'll alter the Gnome experience.

[Chris Halse Rogers (raof)]

There is a recently introduced bug in Compiz in Jaunty which causes this
for gnome users. That is unrelated to this KDE bug, though.

[Vinod (vinodkutty)]

I'm trying KDE again, on Fedora 11, after a long stretch of using GNOME.

I really like Gnome-Do (kudos to the author!) and don't want to leave it behind; looking forward to a fix for this issue.

Instead of the afore mentioned workaround, I've tried to use "Docky" mode and that seems to work (i.e. Do appears above other windows when I hit Super-SPACE) in Fedora 11 (KDE 4.2.2 ).

[Alex Launi (alexlauni)]

Pretty sure this is the window manager's fault, can we mark this as invalid/fixed/wontfix?

[Chris Halse Rogers (raof)]

On Thu, 2009-06-25 at 08:59 +0000, Alex Launi wrote:
> Pretty sure this is the window manager's fault, can we mark this as
> invalid/fixed/wontfix?
>

It certainly is the WMs fault, but it's possible that we might want to
do something about it. Eventually. Other WMs might also be looking for
the specific signs that KWin is looking for to work
focus-stealing-prevention.