Arch Linux User Repository

When library names like libprotobuf.so.XX change you just need to rebuild compiz. It's not a problem with the PKGBUILD. This is normal for AUR packages. Packages in the official repos also get rebuilt when libraries are updated.

Note that you shouldn't symlink new library names to old. This will create problems for you further down the line.

Ok well I had a look at the code that was removed. The code for plugins/kdecompat doesn't look like it's using any code from KDE/Qt. The code for plugins/kde on the other hand - which apparently "Integrates the KDE/Qt event loop into Compiz" - has definitely not been ported to KDE5. It's using classes like KApplication and KCmdLineArgs which come from kdelibs4.

So without kdelibs4, plugins/kde won't compile and I would assume that plugins/kdecompat won't work without it. There doesn't look like there's much kdelibs4 specific code; it probably shouldn't be that difficult to replace it, just following the porting guide. But I don't know whether thumbnail previews in dockbarx would work even if the code were ported. It all depends on whether KWin 5 exposes its window thumbnails in the same way the KWin 4 did. Apparently KWin 4 exposed them through dbus [1].

If I get some time at the weekend I'll experiment with this and see if I can get it working but I can't make any promises.

[1] https://bugs.launchpad.net/dockbar/+bug/1329241/comments/1

EDIT: I had a go at porting the kde events plugin to Qt5 and got so far but reached a brick wall with the dispatcher. The dispatcher seems to get raw XEvents and then use Qt4 to process them. But in Qt5 the code for handling XEvents has been removed and I don't think it's straightforward to work around that, not without a much more detailed knowledge of X than I have. In any case, I think I was wrong in assuming that kdecompat needs the kde plugin so it's probably not relevant.

@Chazza, muktupavels: I wiped out kde/plasma from the system (pacman -Q | grep -i kde and pacman -Q | grep -i plasma returns nothing) and rebooted. Then got the source as Chazza advised and here are the answers: - compilation finished without any problem, the same with installation - ccsm now shows KDE compatibility option - DockBarX not surprisingly doesn't show window thumbnails now. I don't know how exactly DockBarX works however as it normally works (on Linux Mint) even if Thumbnail Window Previews option is off in CCSM I would say that functionality is taken from some KDE library (and this is the reason why it needs KDE compatibility ability in Compiz to work) and so I guess once KDE libraries are installed again, window thumbnails would be back - will test it later. Also I will try if plasma (KDE5) libraries are enough to work, in other words if outdated KDE4 libs aren't needed. It is a question if drop KDE compatibility if it works only with KDE4. It seems it is not causing any troubles (no problems with build), the worse that can happen is that it is just doing nothing. So I would say keep it but i'm not decision maker nor compiz developer. And last but not least, I have saved all compilation output to a file using script command. It has 33kB zipped. If useful i can provide it.

EDIT: actually not all thumbnails are gone. Some applications yes, some not. I don't know what causes the difference. xfce terminal emulator and firefox shows thumbnails whereas krusader and skype not... The only what is absolutely sure, if KDE compatibility is deselected in CCSM empty windows are shown instead of thumbnails.

@denjack as per muktupavels' comment, could you try building Compiz 0.9.13 (without KDE4 dependencies installed) and seeing if it works for you?

You can build older versions of packages by cloning the git repository and then checking out a previous commit. In general, you can see the list of git commits by running git log in the git repository. But for this case you need to do the following:

git clone <https://aur.archlinux.org/compiz.git>

cd compiz

git checkoutc1a346ae6e69

Sidenote: don't believe what compiz.org says. It is barely maintained. I'm actually surprised it even says that 0.9.13 is the latest version. It said that 0.9.8 was the latest version for years and years, even though that came out in 2012.

Does kdecompat works without KDE deps? And works with newest KDE? If so there should not be problems to restore kdecompat plugin...

Chazza: Ah, see your EDIT notice now. That is an exaplanation, thank you. Bad news. No window thumbnails in the future it seems. Thank you very much for help.

@Chazza: You are probably right (some dependencies are perhaps missing at the end) but i think the key is other thing - Mint package is of version 0.9.13 whereas yours is 0.9.14. I checked compiz.org for details and noticed 0.9.13 is shown there as the latest stable 0.9. version. Strange... I downloaded it and unpacked. I saw plugins/kdecompat dir under 0.9.13 version whereas it is missing in 0.9.14 (link here among sources links). Tried to adjust PKGBUILD to use 0.9.13 instead of 0.9.14. I needed to comment out processing of two patches (reverse-unity-config and ccsm-unicode-fix) as prepare() section was failed on it (which is understandable). Now i'm fighting with missing files. May be dependecies issue may be not, i'm not so experienced but the name of the missing file doesn't seem to be related to kde, rather compiz itself (i see warning message "FindCompizConfig.cmake" file not found in cmake module directories.). Will see but it seems obvious to me that the source package is the matter. How you came to that incomplete 0.9.14 version if latest one is 0.9.13?

@denjack Can you have a look at that Mint package and see what the make dependencies are? The build system is most likely disabling compilation of kdecompat because of a missing dependency. I know for sure the kde-window-decorator code was never ported to KDE5. That's probably true of kdecompat as well. Do you have the KDE4 kdelibs package installed? You will surely need that at a minimum.

EDIT: I just checked and as it turns out KDE4 support was dropped upstream for the 0.9.14 release so that explains that. https://git.launchpad.net/compiz/commit/?id=a55d3fb3fc6cdeeae69baffe0ebb9ca84679a692

You will have to either stick with 0.9.13 or reverse apply the commit I linked to above. Sorry about that.

Hello Chazza, thank you for providing this package. Please why there is missing KDE Compatibility plugin in the package? I can see Gnome Compatibility and MATE Compatibility in CCSM but not KDE. KDE Compatibility is needed to have window thumbnails in DockBarX which is the most important, if not the only reason why i'm delaing with compiz. Noticed this plugin is available in Linux Mint compiz package version 0.9.13 i looked for it, but there is absolutely no information about it over the internet. Just as an attempt i tried to change -DBUILD_KDE from Off to On in PKGBUILD of your package and recompile it but no change, even no KDE decorator (the meaning for this configure option as far as i know) have appeared then. Do i something wrong or is the KDE Compatibility really missing in your package and if so why or how it can be add there? Thank you

@Chazza: Even I'm going to read those wiki pages to see other interesting thinks realated. Now I have a new knowledge that is makepkg with "si" argument, and like some other users, after "rebuilding" Compiz now works as good as always. Thanks a lot!

Hello xebuzer0

Documentation for the AUR can be found here: https://wiki.archlinux.org/index.php/Arch_User_Repository

I suggest you have a good read through. In fact, all documentation relating to Arch Linux can be found on wiki.archlinux.org. Just search it for your topic of choice.

To very briefly summarise the building part though, the way you build a package is you download the source package (either by going to the package webpage and clicking "Download snapshot" and then extracting the contents of the tarball or by running git clone <https://aur.archlinux.org/compiz.git>). Then you open a terminal inside the directory containing the source package contents and run makepkg -si. The -s option prompts you to install missing dependencies and the -i option prompts you to install the built package. To rebuild, you simply run makepkg again. You first need to remove the .pkg.tar.xz package created last time (assuming the build succeeded) and you might also need to remove the src directory as well if patch is complaining that there are patches that have already been applied.

As for symlinking new library names to old, please, please don't do this. It is NEVER a good solution. Shared library versions don't change for no reason. They change because the new library is not completely completely compatible with the old. If the program linked against the shared library depends on functionality that changed between the old and new versions of the library then you will run into strange problems and nobody will know what's going on. Also, you will get into a mess because you will lose track of which symlinks were created by you and which ones were created by the package manager.