Issues with Kicker and desktop switching

[Consequence_9]

OK, now before everyone starts shouting "USE THE GOOGLE" and "THE FOURMS HAVE SEARCH FOR A REASON" just listen up, this is a different problem =]

Down to business. My ailments are as follows:

1) Kicker dock is staying above everything, even though it is set to allow windows to cover it. It just started doing this out of the blue. It worked fine one minute, and now it doesn't. What I find interesting is that it it is even staying on top of the windows when using the scale plugin and it is even staying above the hot-corners. I have already tried to set it to stay below everything using the window rules plugin to no avail. I'm sure it is some kind of priority issue, but everything seems set correctly. I've tried doing a killall kicker and restarting it, but that doesn't work either...

2) Desktop switching, but not your normal issue. I have it set to edge flip on pointer, now whenever I have a maximized window open it will not flip when my pointer hits the edge. Also I have noticed that when dragging a window and flipping, it will only flip back and fourth once or twice, and then it will stop flipping...

Any help would be much appreciated, and thank you for taking the time to read! =]

[Deciare]

OK, now before everyone starts shouting "USE THE GOOGLE" and "THE FOURMS HAVE SEARCH FOR A REASON" just listen up, this is a different problem =]
I don't ask people to search. I like having an audience for my long-winded compositions. :P

1) Kicker dock is staying above everything, even though it is set to allow windows to cover it. It just started doing this out of the blue. It worked fine one minute, and now it doesn't. What I find interesting is that it it is even staying on top of the windows when using the scale plugin and it is even staying above the hot-corners. I have already tried to set it to stay below everything using the window rules plugin to no avail. I'm sure it is some kind of priority issue, but everything seems set correctly. I've tried doing a killall kicker and restarting it, but that doesn't work either...
How strange. Have you tried restarting Compiz? Maybe it's just a random glitch.

Or maybe Kicker's configuration is somehow out of sync? Open ~/.kde/share/config/kickerrc, and ensure that this option is set correctly:
[General]
BackgroundHide=true
Then run this command to reload Kicker's configuration:
dcop kicker kicker configure

2) Desktop switching, but not your normal issue. I have it set to edge flip on pointer, now whenever I have a maximized window open it will not flip when my pointer hits the edge. Also I have noticed that when dragging a window and flipping, it will only flip back and fourth once or twice, and then it will stop flipping...
Are we talking about flipping a non-maximised window over to another viewport when a different window is maximised in the background, or are we talking about flipping the maximised window to another viewport?

If it's the second issue, you need to enable the option at ccsm->Move Window->Snapoff maximised windows. Oh, I just did some testing, and it doesn't seem to work either way if you're managing viewports with a Cube; it works fine with the desktop Wall, though. If it's the first issue... I don't know. ^^; It's the first time I've seen anyone ask that question.

[Consequence_9]

I don't ask people to search. I like having an audience for my long-winded compositions. :P
=]

How strange. Have you tried restarting Compiz? Maybe it's just a random glitch.
Uh huh, I restarted it a whole buttload of times, even tried resetting o_O (oh god... conditioned windoze reflex, even in affect two years after the switch)... What I noticed was that it works normally for about 30 seconds or until I rotate the cube... I tested it with my two bottom hotcorners, but after that - nothing.


Or maybe Kicker's configuration is somehow out of sync? Open ~/.kde/share/config/kickerrc, and ensure that this option is set correctly:
[General]
BackgroundHide=true
Then run this command to reload Kicker's configuration:
dcop kicker kicker configure
Thanks, I tried that, but it didn't seem to work. What was interesting though was the altogether absence of that variable from the config file. One would assume it would at least be there if only in the false position.


Are we talking about flipping a non-maximised window over to another viewport when a different window is maximised in the background, or are we talking about flipping the maximised window to another viewport?
Talking about just any old window as its selected.

Something else i noticed about this that is really odd, it won't flip if a window, any window, is wrapped between the two desktops. It will flip the pixel above or below the wrapped window, but not if your pointer is touching it... o_O

If it's the second issue, you need to enable the option at ccsm->Move Window->Snapoff maximised windows. Oh, I just did some testing, and it doesn't seem to work either way if you're managing viewports with a Cube; it works fine with the desktop Wall, though. If it's the first issue... I don't know. ^^; It's the first time I've seen anyone ask that question.
Hmm... That option is already enabled... I'm at a loss here... but hey, i'm glad i'm offering up a new challenge, lol

Thanks for being so prompt, even if its not working yet, u know the whole bit about two minds, lol

[Deciare]

Talking about just any old window as its selected.

Something else i noticed about this that is really odd, it won't flip if a window, any window, is wrapped between the two desktops. It will flip the pixel above or below the wrapped window, but not if your pointer is touching it... o_O
Well, you see,
I completely misunderstood your question.
Now that I understand your question, I still can't reproduce either of the problems you mention.
You got me to switch back to using Cube because this is interesting. Congratulations. XD

Would you mind putting your whole ~/.config/compiz/compizconfig/Default.ini file online? Maybe pasting it to Pastebin (http://pastebin.ca)? I'd like to see if I can reproduce any of your problems using your exact configuration.

You have some of the most unusual problems of anyone here. And one of the most unconventional styles to go with it. XD

[Consequence_9]

lol, wow, i feel special =] Here is the pastebin url: http://pastebin.ca/664067

My guess is that it has something to do with all that jumbled code about kicker down at the bottom under window rules, which is really odd because i just looked at it and i have no mention of kicker in my winrules, i DID, but i deleted the instance after changing its settings didn't work.

Also as a completely unrelated problem *drumroll please*.... my window preview plugin just doesn't work, it worked once, a long long time ago, but now nothing happens when i enable it, and i'm sure it isn't a mismatch of build versions or anything like that, it hasn't worked for a while, I'm using the latest git build... anyway that problem i should probably save for another rainy day...

Thanks for the help!

Update: I'm putting my money on it being a window priority issue, I just started listening to music, and the amarok OSD is appearing behind windows, which has never happened before, it was always right on top like it should be... hmmm.... i'm thinking this could possibly have something to do with the widget plugin, it could be screwing up my window priorities....

Update 2:: *sigh* guess it wasn't all that jumbled code, got rid of it all, saved, restarted & got the same problems...

[Deciare]

WHAT...

That config file looks severely broken. It has to be the single most broken compizconfig file I've ever seen! I can only imagine that trying to process that file would do to Compiz. o.O

Could you try completely deleting that file and recreating your configuration with ccsm, to see if it your settings work more predictably? That would be easier than trying to pick out all the jumbled code. It's not just near the bottom, it's all over the place.

How did the file become that corrupt in the first place? Might your hardware be suffering from memory or disk corruption?

Edit: When you said that you are using the latest git build, exactly how late is that? And from whom or where did you get it? Some major changes went into Compiz Core about 3 days ago that have the potential to cause some very significant breakage in the compizconfig system (though I had no idea they were this significant).

[Consequence_9]

LOL, beats the hell outta me as to how it got so corrupted. I tried what you said; deleting it and reconfiguring seems to have solved the two major problems of no edge flip on pointer and the taskbar above all. However there are some underlying issues which I actually think are inter-related. When I had a totally empty configuration I tried enabling window previews, and for the first time since switching to Fusion they worked! It was short-lived however. When I set the KDE takbar back to allow other windows to cover it (in the KDE control center, not ccsm) the feature promptly stopped working, putting me in a bind... Thanks to that though I know that it is a window priority issue....

The corruption of the file however may be the side affect of some other problem. I think it may be a bcop problem. Here's an example: After I got everything working more or less peachy keen I noticed that the lovely screensaver plugin was not installed (which makes sense since I removed all the old plugins so as to do a clean install of compiz to avoid version mismatch confusion). So, like every fusion addict, I went straight to Git Web, opened up a command line and cloned the plugin. I did everything I normally do, I su'ed myself to root, cd'ed into the directory, and since there is no ./configure for this one, I typed make. When I did, this is the output I received:

[root@localhost screensaver]# make
convert : screensaver.xml.in -> build/screensaver.xml
bcop'ing : build/screensaver.xml -> build/screensaver_options.h/bin/sh: --header=build/screensaver_options.h: No such file or directory
make: *** [build/screensaver_options.h] Error 127


As one can see the error occured during bcop'ing... I'm not sure what to do here... I got the two worst problems out of the way, only to be left with two more:

1) The window priority problem preventing the beloved window previews plugin from working
2) The bcop problem which is not allowing me to build ANY plugins...

Your Ideas are not going unappreciated =]
Thanks for your help before! =D

[Consequence_9]

Sorry for the double post in advance, but now this is starting to tick me off. Its Doing exactly what it was doing before... I have no idea why, but it would appear that the Default.ini keeps getting corrupted. I mean it was totally random, i didn't change a setting or anything, it just started happening again... I'm sure that there is nothing wrong hardware wise because i'm not experiencing any other problems, so it seems to be a software issue....Any ideas?

*update*: well, i was able to narrow it down to specifically what causes the corruption. It is the window rules plugin - more specifically anytime I type in "name=superkaramba" under keep above. When I don't do this however, my superkaramba widgets stay beneath my windows when the widget layer is brought up... I'm not sure what to do about it...

[Deciare]

Ooh, a correlation! How exciting! >w<

What happens if you don't type name=superkaramba into the winrules plugin, but type it into a different window, copy it, then paste it into the winrules configuration page?

(I read your other post, but I can't really comment on them until I get on a computer with Compiz installed.)

[Consequence_9]

hmm... well i just tried that and it didn't work, but it did confirm my suspicion about it somehow being related to the widget overlay. I pated it and hit back so it would save, it was fine for a second, i moved a window over the taskbar and it stayed on top, but when i activated the widget layer the window immediately sank through the taskbar... its a good thing i backed up a working .ini =]

[Deciare]

Sorry, but I can't confirm the problem you're having with the widget layer. Whether with or without the widget layer enabled, Kicker works fine both ways: allowing and not allowing other windows to cover the panels.

I've noticed that child panels tend to have problems toggling in and out of allow-others-to-cover mode, though. When that happens, I have to
killall kicker
kicker &
in order for the setting to work.

Do you have any winrules specified? Do you have any window matches specified in the Widget Layer configuration page? Maybe my configuration isn't close enough to yours for us to see the same problems.

Ooh, but I was able to royally mess up my Default.ini by typing things into the winrules plugin, so you're not alone there! :)

[Deciare]

More testing. It appears that typing things into a window matching rule field doesn't directly corrupt the Default.ini file, but any action that causes any portion of the field's contents to be deleted, including:
Backspace key
Delete key
Pasting over what was previously in the field
Pressing the clear/default button (where a non-default value is already present)

The amount of Default.ini breakage appears directly proportional to the number of characters deleted or overwritten: one character is corrupted for each character deleted or replaced.

An action that affects the interpretation of window matching rules, such as enabling or disabling the Workarounds plugin, will also cause Default.ini corruption.

This problem is likely not caused by any specific plugin, since it happens even with only a minimal set of core-only plugins (decoration, place, resize, png, dbus, cube, switcher, move, scale, rotate) loaded.

I wonder if we're the only ones having this problem? If not, a bug report ought to be filed about this.

Edit: I submitted a bug report. Bug 362 (http://bugs.opencompositing.org/show_bug.cgi?id=362) on bugs.opencompositing.org .

[Consequence_9]

Well I guess this is a case closed then. The problems all root from the corruption of the .ini file.

I guess as a temporary workaround one could manually edit the .ini, of course one would first have to know the associated variables...

hmm... still having that stupid bcop issue, as well as the lack of window previews =[ ... think i'll fo some more testing and start a new topic if i get nowhere...

Thanks a lot for all your help on this one! I appreciate it =]

[Deciare]

I can't reproduce your problems with window previews or bcop, so I'm afraid I won't be much help there. :/

Er, actually, this is kind of a dumb question, but do you actually have bcop installed?
which bcop
What does that command return? Since you know your way around Linux, it's probably not that, but... Well, it can't hurt to ask?

You can find out exactly what a window-match rule's variable is called by looking up the XML file corresponding to the plugin whose option you wish to edit. Window Rules is described by /usr/share/compiz/winrules.xml, for instance. If you look in the file, you'll see that the variable for the Above field is called "above_match". Prepend "s0_" to that name, and you'll have the variable name in Default.ini: s0_above_match.

As for editing the .ini file, you'll thankfully only have to do that for window rules. You can still use ccsm for everything else*. :)

*Probably.

[Consequence_9]

The command returns:

/usr/bin/bcop

So I'm assuming its all in place. It honestly just stopped working.... maybe its something vaguely similar to this, a corrupted file somewhere or something. I'm not sure if i should risk just removing it and re-installing it, as that could either fix it or screw a lot of other things up... As for the .ini editing I actually just guessed it would be s0_above_match from looking at the previously set s0_widget_match. Its always nice to have variables that have some pattern to their names. =]

As for window previews, i might just try to edit the .ini file a bit more to turn that on just because ccsm is screwin up pretty bad for me right now... I'm sure it has something to do with window priority, i only i knew what...

[Deciare]

I have issues with window priority, too. For no apparent reason, my rule to keep Kicker's animated tooltips above other windows (class=Kicker & role=animtt) would simply stop working. I think it has to do with changes that the Workarounds plugin makes to the way windows are matched (KDE menus, tooltips, dropdown lists, passive popups, animated tooltips, and other stuff are all kinds of non-standard, and Workarounds tries to account for that). But it still doesn't explain why the animated tooltips are sometimes above and sometimes below other windows.

Oh. Come to think of it, what do you suppose would happen if you simply disabled the Workarounds plugin?

[Consequence_9]

Well, i tried disabling the workarounds plugin, all it did was break the window priority of amarok's current track OSD, lol, unfortunately no window previews =/ ... I'm also totally at a loss with the bcop error... Got the latest version off gitweb, did the usual ./autogen.sh, runs through its checks only to stop with the error "No package 'libxslt' found"... now i know for a fact that this is installed, but just to humor it i hit the google and download it within a minute. Time for make install... it exits telling me the install was recursive.... =/ now I'm frustrated... bcop is telling me that its not installed when it is, i even tried the global flag modifiers --without-xslt and --without-libxslt, to no avail... what could be wrong here? I miss my screensaver plugin =[

[Deciare]

The configure script's probably searching for /usr/lib/pkgconfig/libxslt.pc. If you have the kind of distro that splits such files into -dev or -devel packages, you'll have to install the corresponding one for libxslt. Unless, you know, you have.

If you're positive that you already have libxslt development files installed on your system, find the pkgconfig file with
locate libxslt.pc
then pass the directory it's in to the autogen script in an environment variable, like so:
PKG_CONFIG_PATH=/directory/where/you/found/it/ ./autogen.sh [...]

[Consequence_9]

Hmm... This is troubling, locate returns that it is right at /usr/lib/pkgconfig/libxslt.pc . Fedora does do that crap with the splitting up into normal and devel files, so just to make sure i had it installed went and got an rpm of it (thank you rpm find =]). Upon installation it told me that a newer version of it was already installed... ok, so I went back to the good ole command line and passed the found directory to ./autogen.sh ... only to get the same error... *sigh*... i wonder what the problem is... version mismatch? could it be a code issue in the new bcop? (just like a missing greater than instead of just equal to?)... maybe i should just try to get my hands on an older version of bcop to see if it works, but where would i get an old version...?

[Consequence_9]

Well after a few days of experimenting i have found nothing. I'm still stuck with the same bugs I had before (the dock staying over all windows). I did however realize that this was only occurring after the activation of the widgit layer, although i cannot tell weather the whole problem is being caused by the widgit layer (it is more likely being caused by some kind of clashing settings, although i don't know what exactly).

Also, Bcop is still broken for me. I tried downloading several older versions, but i still got the same damn error "No package libxslt found", etc.. This is probably the biggest problem here as I wont be able to upgrade to the latest plugins/(ccsm?)... Any suggestions? =[

Thanks and my apologies for the double post...