dennyhalim / wbar

Automatically exported from code.google.com/p/wbar
GNU General Public License v3.0
0 stars 0 forks source link

wbar use own image as background #66

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Steps to Reproduce:
1. Run wbar
2. Click on any "launch" icon (not from "Task Manager" side)
3. look at GUI artifact:
Seems that wbar get own image(screen-shot) and use as background.
I have checked list of processes, and no any other instance run.

Version:
- Latest Dev version at Jan 23 13:11 GMT

Environments:
- Slackware 13.37.0
- Linux 2.6.37.6-smp #2 SMP Sat Apr 9 23:39:07 CDT 2011 i686
- KDE 4.5.5

Original issue reported on code.google.com by alexeyle...@gmail.com on 23 Jan 2012 at 4:15

Attachments:

GoogleCodeExporter commented 9 years ago
Artifact disappearing after refresh

Original comment by alexeyle...@gmail.com on 23 Jan 2012 at 4:18

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Reproduced only under root account
So updates of STR: 
- login as root
- start window manager (tested on xfce 4.6.2 and kde 4.5.5)
...

Original comment by alexeyle...@gmail.com on 31 Jan 2012 at 4:14

GoogleCodeExporter commented 9 years ago
While using E17, at last I was able to reproduce that reliably.

The problem is, most X software that utilizes pseudo-transparency just 
snapshots a RootWindow image, and some smarter software also tries to acquire a 
background from an FM-desktop window. If both methods fail, their last resort 
is just posting a reply 'set the root background with some known utility' to 
bugreports and forums.

In wbar, historically we also stumbled upon a thing I now call a 'last-resort' 
mode, where wbar would try to snapshot the whole screen to acquire a background 
image.

And here, a bug went in when our taskbar feature was introduced: at the first 
snapshot, the things went well. But adding a new icon to a taskbar required to 
refresh the background, and the image was taken again, from a screen that 
already contained the bar. Hence the problem.

There is another aspect of the problem.
In a related issue #79, we could see a problem similar to what is described 
here: a WM was able to launch wbar before it could set the root background, so 
there were artefacts until wbar was reloaded and was able to acquire a set 
background.
In issue #75, a workaround, rather than a fix, was suggested: make wbar sleep 
for 2 seconds before appearing. Unfortunately, this could work for a particular 
user who knows that some particular environment needs two seconds to set a 
wallpaper, but not for the rest of the users.

So, why so many characters here?

All the mentioned problems need to be fixed by improving the snapshotting 
routines. So, I will link two other tickets here, and keep all three of them 
open until the issue is fixed. Please don't fix the other two issues 
separately, because it could break the things even further.

Original comment by ivan.fit...@eltrino.com on 24 Mar 2013 at 9:05

GoogleCodeExporter commented 9 years ago
reproducible if no xcomposite are enabled, event have task manager or not

when enable composite, problems solved.

Original comment by mckayger...@gmail.com on 3 May 2013 at 7:16