release tags

[hasufell]

will we get some usable release/prerelease tags?

It's hard to follow as a packager. (note that compton is already in gentoo)

[mariobl]

Indeed, it would be easier for us. I'm the compton package maintainer for Fedora, and I would really appreciate it.

[richardgv]

1. I've always been hoping to create our first formal release, but I somehow have never found a good chance. :-S I'm truly sorry for the situation.
2. I would like to consider the current state of the master branch basically stable. If everything goes well, after 2 weeks of testing I will create a tag. (Huh, do you have any suggestions about how much time I should wait before pushing out our first release? Are 2 weeks too long, or too short? I have no experience on this part. ebuilds generally take 30 days before stabilization, right?) I have two pending commits (remote control over D-BUS and a new, more powerful window matching system), yet I estimate they would include over 1,500 lines of additional code so they can't be stabilized soon, and they are not necessary features.
3. I'm a Gentoo user myself, and the fact that Gentoo already has compton in Portage tree kinda makes me less enthusiastic in creating tags. :-D
4. @mariobl: Thanks for packaging compton. :-)
5. @hasufell: Thanks to you, too. :-) By the way, the ebuild should build the man pages with Asciidoc (make docs), as mentioned in the "known issues" part of the README.

[hasufell]

2: That is up to you. Also, what is "stable" for the distributor and for you are two different things.
(and no... 30 days is not a rule, it's just common practice)

5: I see. You should run "make docs" yourself for release tarballs (you should create release tarballs in addition to git tags), because this adds a build time dependency on app-text/asciidoc.

[SmilingHorse]

Don't forget Debian! Here's a little teaser of my new Raspberry Pi running compton and openbox with debian wheezy:

Just to pique your interest :D

[richardgv]

@hasufell:

2: That is up to you. Also, what is "stable" for the distributor and for you are two different things.
(and no... 30 days is not a rule, it's just common practice)

Ah, I see. Thanks.

5: I see. You should run "make docs" yourself for release tarballs (you should create release tarballs in addition to git tags), because this adds a build time dependency on app-text/asciidoc.

I saw the ebuild being updated, thanks.

Yeah, definitely this should not happen on release tarballs. Thanks for the advice.

@SmilingHorse:

Just to pique your interest :D

1. Are you thinking I'm losing interest on compton? Well, this is partly true, I'm feeling weary, but compton has become a responsibility instead of a work of interest since chjj's departure. :-D
2. I'm still working on D-Bus support and advanced window matching. Terribly slowly, with my dad's presence. (If he stays with me in this winter, I will have to continue working at the speed of 100 lines per day...) The window matching part is almost finished (700+ lines...) but is untested; the connection part of D-Bus support is finished, I'm working on DBusWatch/DBusTimeout handling.
3. Yeah, libdbus is not the most awesome library in this world. I do have my reasons to stick to D-Bus, and I found writing code silently more efficient than arguing, though. That's why I haven't replied to your last post.

Here's a little teaser of my new Raspberry Pi running compton and openbox with debian wheezy:

Looks great! :) I'm glad it works under such weak GPUs.

By the way, the font you used in the terminal looks cool. What is that?

[SmilingHorse]

@richardgv

1. Oh well, I just assumed once the stuff you wanted are done and there's nothing terribly exciting left to do, you'd get bored and move on. As you should ;) You cleaned compton up and added a whole range of features and functionality dragging the old thing kicking and screaming into a point where adding anymore wouldn't be practical... And now you're saying you're mostly on your own... Well, I just wanted to let you know there's a potential user base waiting for you out there in the low-power embedded world that should viable for a few more years.
2. That's some interesting news. I was under the impression you were looking for a dbus alternative since the library was a mess ?! Well, it's good to see you figured it out and am running with it after all. Any addition that doesn't pile up excess dependencies or spoil performance is good news. :)
3. Sorry I came off argumentative. That was never my intent. My concerns were purely technical based on performance (I had poor experience with high-level sockets), fear of adding more dependencies (glib and bindings were mentioned), and code maintenance (high level libraries change APIs without backwards compatibility). But, you went ahead with the low-level libdbus so while I fell sorry for you, I'm actually all for it :D

• "Looks great! :) I'm glad it works under such weak GPUs."

It's pushing the CPU\GPU pretty hard so I only run it with a minimal set of features... The Pi is actually proving to be a really useful and cheap testbed for performance tuning. Makes me want to get back into C :P

• "the font you used in the terminal looks cool. What is that?"

Really?! I find it quite blocky and ugly and only use it as a safe default and to test out compatibilities... Nonetheless, here you go:

~/./mlterm/aafont:

DEFAULT = 24,unifont 24
ISO10646_UCS4_1 = 24,unifont 24
DEC_SPECIAL = 24,unifont 24


~/./mlterm/main:

fg_color = white
bg_color = black
sb_fg_color = lightgray
sb_bg_color = black
logsize = 4096
bel_mode = none
scrollbar_mode = right
scrollbar_view_name = simple
use_clipboard = true
geometry = 80x35
compose_dec_special_font = true
use_anti_alias = true
fontsize = 24
letter_space = 1
mod_meta_mode = none


Here is what I prefer for day to day usage:

~/./mlterm/aafont:

DEFAULT = 21,DejaVu Sans Mono 21
ISO10646_UCS4_1 = 21,DejaVu Sans Mono 21
DEC_SPECIAL = 21,DejaVu Sans Mono 21


~/./mlterm/main:

fg_color = white
bg_color = black
sb_fg_color = lightgray
sb_bg_color = black
logsize = 4096
bel_mode = none
scrollbar_mode = right
scrollbar_view_name = simple
use_clipboard = true
geometry = 80x35
compose_dec_special_font = true
use_anti_alias = true
fontsize = 21
letter_space = 1
mod_meta_mode = none


[richardgv]

@SmilingHorse:

Oh well, I just assumed once the stuff you wanted are done and there's nothing terribly exciting left to do, you'd get bored and move on. As you should ;) You cleaned compton up and added a whole range of features and functionality dragging the old thing kicking and screaming into a point where adding anymore wouldn't be practical... And now you're saying you're mostly on your own... Well, I just wanted to let you know there's a potential user base waiting for you out there in the low-power embedded world that should viable for a few more years.

Thank for the praise. Despite the fact that "code clean-up" is the phrase I most commonly use in commit messages (50+ times in total?), I bet my changes are making compton dirtier, though. The internal logic is a whole mess.

That's some interesting news. I was under the impression you were looking for a dbus alternative since the library was a mess ?! Well, it's good to see you figured it out and am running with it after all. Any addition that doesn't pile up excess dependencies or spoil performance is good news. :)

You are right, it's a nightmare. I have to handle all those timeout things myself. (Guess that's why high-level dbus API is always associated with a big library -- dbus itself requires many auxiliary things.) chjj stated he doesn't like glib last time, so I guess I need to stick to libdbus.

Sorry I came off argumentative. That was never my intent. My concerns were purely technical based on performance (I had poor experience with high-level sockets), fear of adding more dependencies (glib and bindings were mentioned), and code maintenance (high level libraries change APIs without backwards compatibility). But, you went ahead with the low-level libdbus so while I fell sorry for you, I'm actually all for it :D

Huh, sorry for giving you the impression that I'm inferring you are argumentative. I just don't have the time to explain all my intentions. Well, just a short explanation: What I want is a high-level IPC that actually counts more as remote control or plugin API. So performance does not matter, and I could not choose the low-level IPC mechanisms unless I wish to handle all the details of a remote control system (like message format, synchronization, listening to commands from multiple clients simultaneously).

It's pushing the CPU\GPU pretty hard so I only run it with a minimal set of features... The Pi is actually proving to be a really useful and cheap testbed for performance tuning. Makes me want to get back into C :P

Ah, I see. :-) You are right, it would be handy for testing performance. It's pretty normal for compton to stress the GPU, but the CPU load is high, too? Have you discovered any features that specifically stress the CPU/GPU much?

Really?! I find it quite blocky and ugly and only use it as a safe default and to test out compatibilities... Nonetheless, here you go:

Oh, that's Unifont! The photo is giving me somehow a different feeling. :-) But thanks for your configuration files.

I keep quite many monospace fonts on my system, and once I'm bored when coding I switch the font. :-D

[SmilingHorse]

"The internal logic is a whole mess"
There's a logic to it ?! :P It's a prototype that gets the job done. Last thing you want to do is wait a decade for a "properly" written stable ;)

"I have to handle all those timeout things myself...chjj stated he doesn't like glib"
Told you so :P In dbus's defense they do warn you in advance you shouldn't use it without an abstraction library. But glib isn't all roses and rainbows either... I'm somewhat apprehensive about suggesting this since it's relatively new and lightly documented, but since you're entering the still worse "reinventing the wheel" danger zone:
https://programcounter.wordpress.com/2012/11/07/edbus/
Dependencies wise, it's only ecore and edbus which is a tiny fraction in comparison to glib. More importantly, it's extremely well written. Just see for yourself:
Here's a client example:
http://svn.enlightenment.org/svn/e/trunk/edbus/src/examples/client.c
And a server one:
http://svn.enlightenment.org/svn/e/trunk/edbus/src/examples/server.c
Well, I don't know enough C to tell for sure, but it looks damn good to me :D Again, I would never have brought it up if I didn't worry you're headed for some trouble... But hey, at least it's a learning experience :D At least in this case someone else spent that decade to write it properly :D

"counts more as remote control"
I think I get it... Then Dbus is probably a good choice :P libdbus still scares the crap out of me mind you :P

"discovered any features that specifically stress the CPU/GPU much"
Opacity, opacity, and opacity :) But, don't bother trying to remote control this one. You won't be able to do much about it unless you're working with one yourself. Hell, I'm not even sure if it's using the GPU or doing it all in software rendering. I'm very unfamiliar with the platform and am too busy with my work to play around with it properly :( I still stand by my suggestion though: It makes a great testbed for performance testing.

"and once I'm bored when coding I switch the font. :-D"
I mostly use Monospace in GVIM, DeJaVu in Terminology and Unicode in mlterm. Mlterm renders most fonts pretty poorly but I IRC in mlterm (epic5) since people sometime use the L2R thing... GVIM is my X default since I like having copy pasting that actually works and I don't remember all the tmux shortcuts too well. I code in Vi (using DeJaVu font) using Terminology. Terminology REALLY looks good. The rendering is the best I've ever seen in a terminal. I think you can emerge it but I just build it off the E17 SVN.

[pvanek]

FYI: the current compton git master is finally "all green" in this repo: https://build.opensuse.org/package/show?package=compton&project=X11%3AQtDesktop

So if there will be a release in few days (current codebase) I can provide RPM packages in minutes.

[richardgv]

Well, sorry, due to the recent bug reports, we can no longer create a tag as promised: We have #74 (cannot compile on *BSD & nvidia-drivers segfault & --sw-opti bad timing on FreeBSD), #73 (timing issue in window data fetching), and #77 (handle non-zero border_width incorrectly). Holy, so many issues all a sudden!

FYI: the current compton git master is finally "all green" in this repo:

So if there will be a release in few days (current codebase) I can provide RPM packages in minutes.

Yeah, I'm truly glad so, although we can't have a release now as stated above.

[DachiChang]

When does the patch and the new feature will merge to master branch ??
I'm use compton on Freebsd 9.1 two weeks, and it's running very well. I test compton with nvidia-driver.

[richardgv]

@DachiChang:

When does the patch and the new feature will merge to master branch ??
I'm use compton on Freebsd 9.1 two weeks, and it's running very well. I test compton with nvidia-driver.

If I get positive feedbacks about the features in #75 and #80, I will merge richardgv-dev branch into master in 2 days, if you insist. (I should say I do not enjoy pushing an unstable D-Bus API to master, though.) But there will be no tags, because I'm already working on debugging c2.c (our new condition format), and D-Bus API will be modified shortly as well. (Recently my personal condition is very much against me. For months has my dad been staying at home watching me 24x7, giving me very little time to work on compton. So don't expect those changes will come out very soon.)

[richardgv]

FreeBSD compatibility and D-Bus support are in master branch now. New condition format code is in richardgv-dev branch. (Expect it to stay there for a while, the new condition format probably isn't very stable.) We have one suspected bug on CrunchBang Forums.

Attention, all package maintainers of compton (@hasufell, @mariobl): Support of automatic versioning based on Git commit hash and date has been merge in master branch, and this requires special care when packaging. I mean, for now. when you run compton -h, compton will print out something like this:

compton (git-6d36ef2-2013-01-28)
usage: compton [options]
...

The version number is generated by calling git command directly, when building. If your source package has Git data stripped, the automatic versioning will not work, and as a package maintainer you should manually export the COMPTON_VERSION variable before building in your building script. Run make version on the Git repo to see the version number compton will use.

For example, this is how could I generate a snapshot and build with it, with right version number:

# Generate snapshot with version in filename
git archive --format tar --prefix="compton-$(make version)/" HEAD | xz > /tmp/compton-$(make version).tar.xz

# Extract the snapshot somewhere...
# Export the COMPTON_VERSION variable (you may also pass it to make directly)
export COMPTON_VERSION=$(echo "${SRC_FILENAME}" | sed 's/^.*compton-\(.*\)\.tar\.xz/\1/')

# Make now
make

As for tagging, well, I guess not before the new condition format gets stable, so...

[pvanek]

hi,
packages has been updated for suse/fedora with new dependencies and versioning.

anyway - I have an issue with --dbus. Running eg.

compton -cC -fF -I 0.065 -O 0.065 -D 6 -m 0.8 -i 0.8 -e 0.6 --dbus

results in black screen. When I kill compton from tty1 all is fine again. Without --dbus all works fine.

[richardgv]

@pvanek:

packages has been updated for suse/fedora with new dependencies and versioning.

Update: Never mind. Silly me. Didn't realize it's the epoch time.

It's recommended to use the version number reported by make version, with the format git-<commit hash>-<date>, instead of your own version number -- I mean for the COMPTON_VERSION exported, for the package version you may use whatever you like. The purpose of this version number is to identify the exact version the user is using, when he reports a bug to us, and unfortunately, I can't know what version 1.0.1.1359005883 refers to.

By the way, our planned next release is 0.1, so a snapshot should normally not have a higher version number.

anyway - I have an issue with --dbus. Running eg.

compton -cC -fF -I 0.065 -O 0.065 -D 6 -m 0.8 -i 0.8 -e 0.6 --dbus

results in black screen. When I kill compton from tty1 all is fine again. Without --dbus all works fine.

The D-Bus module is separated from the core, and it should not cause malfunctioning of the core unless it's blocking the main thread. I assume compton had some troubles connecting to D-Bus or checking for incoming events on your system, a blocking condition. I would recommend to check if your D-Bus session bus is working correctly.

If you still don't have a clue, please build compton with debugging symbols:

make clean; CFLAGS='-ggdb' make

libdbus should be built with debugging symbols, too, if possible.

Then please use gdb to launch compton --dbus from a virtual console. When you see black screen on X, interrupt compton, and obtain a full stacktrace. If you couldn't see what's wrong, please post the output here.

[guiniol]

I've been trying out the richardgv-dev branch and it seems that the dbus commands doesn't get the windows ID right. If I list_win, none of the ID correspond to what xwininfo gives.
Has anyone else experienced this?
I'm using fluxbox if that matters

[richardgv]

@guiniol:

1. Compton gives out the window IDs from internal window list which is also used for rendering and all other operations. If compton really got the wrong window IDs, it would entirely break.
2. In case you don't know, compton list_win gives frame window IDs, while xwininfo and xprop uses client window IDs by default when selecting. xwininfo -frame could be used to get frame window IDs. com.github.chjj.compton.find_win string:client uint32:<Client window ID> could be used to find frame window ID based on client window ID. com.github.chjj.compton.win_get uint32:<Frame window ID> string:client_win could be used to find client window ID based on frame window ID.
3. If you could confirm compton is giving out wrong frame window IDs, but is operating correctly, then there are two possible causes, as far as I could think of right now: 1. issues during internal type conversation, Window is not correctly converted to uint32_t. I think this may happen if you are using unusual architectures (arm, sparc, ppc(64)...) or unusual compilers. 2. issues when appending the argument. Maybe D-Bus is somehow using inconsistent types with compton?
4. This problem should be unrelated to the WM you use.

[guiniol]

Thank you for the quick reply, and sorry if you felt assaulted, that wasn't my intention at all.
Thank you also for compton, which I only just started playing with yesterday but already fills the spot xcompmgr should have.

If you could confirm compton is giving out wrong frame window IDs, but is operating correctly, then there are two possible causes, as far as I could think of right now: 1. issues during internal type conversation, Window is not correctly converted to uint32_t. I think this may happen if you are using unusual architectures (arm, sparc, ppc(64)...) or unusual compilers. 2. issues when appending the argument. Maybe D-Bus is somehow using inconsistent types with compton?

I had no idea there were different client and frame window idea.
Compton indeed gives the right frame window IDs.
However, using dbus, the find_win string:focused always gives out 0 whether I set use-ewmh-active-win to true or false.
I'm using: compton (git-2182505-2013-02-05)

[richardgv]

Thank you for the quick reply, and sorry if you felt assaulted, that wasn't my intention at all.
Thank you also for compton, which I only just started playing with yesterday but already fills the spot xcompmgr should have.

Huh, did I appear assaulted somehow? :-) Sorry, I am in some moderately bad mood recently that I frequently appear aggressive.

And thanks for help testing D-Bus support. :-)

I had no idea there were different client and frame window idea.
Compton indeed gives the right frame window IDs.

Cool. :-)

However, using dbus, the find_win string:focused always gives out 0 whether I set use-ewmh-active-win to true or false.

That's intentional. Compton does not track window focus unless you use an option that forces it to do so -- -i (inactive-opacity), --inactive-dim, or focused in one of the conditions. use-ewmh-active-win affects the method compton determines focus, but doesn't let compton track focus itself. It's easy to acquire the focused window by querying X, and find_win is provided for mere convenience. If you have a reason to rely on find_win string:focused, just enable one of those options and compton shall be able to return the focused window for you.

[guiniol]

Huh, did I appear assaulted somehow? :-) Sorry, I am in some moderately bad mood recently that I frequently appear aggressive.

It's just that I tend to forget to write polite greetings and that kind of stuff.

And thanks for help testing D-Bus support. :-)

Thank you for implementing it.
Actually I managed to get a script working so that I can invert colors on a window. It doesn't seem to be cpu intensive by the way.
Anyways, I don't know if I'll be playing with it much more since what I want works, but if you need anything in particular tested, just tell me. I'd be glad to help.

[richardgv]

@guiniol:

It's just that I tend to forget to write polite greetings and that kind of stuff.

To be a gentleman is not as important in the cyberspace as it is in real life, I hope. :-D Greetings don't really matter here.

Actually I managed to get a script working so that I can invert colors on a window. It doesn't seem to be cpu intensive by the way.

Oh, that's cool. I didn't think so many people would enjoy color inversion. :-)

And by the way, I hope with the new condition format (currently in richardgv-dev branch) in most cases --invert-color-include is enough for matching windows and using D-Bus isn't usually necessary.

Anyways, I don't know if I'll be playing with it much more since what I want works, but if you need anything in particular tested, just tell me. I'd be glad to help.

Ah, thanks! :-) Presently, we have nothing that really need testing.

@pvanek:

Hmm, sorry for disturbing you, but quite some days have passed since you reported the issue related to --dbus. I believe you've read my reply about the problem, right? Any progress?

[pvanek]

oops. Sorry, I forgot about it. But unfortunately - no progress. Blank black screen with mouse cursor and no relevant stack:

(gdb) ^CQuit
(gdb) bt
No stack.
(gdb) Killed

[richardgv]

@pvanek:

Update: My friend says it might be related to -fomit-frame-pointer. You aren't using it when compiling compton, right? Also, just a double-check: You have used -ggdb, right?

Update 2: man gcc says -fomit-frame-pointeris the default on i386, so, you probably need -fno-omit-frame-pointer?

Oh, no stack?! Hmm, my knowledge about gdb is rather limited, and the only situation that I know in which gdb could report "no stack" is when the program is not actually run when you run bt, which should definitely not happen. Well, the output you posted doesn't look correct. I mean, here it looks like this:

$ gdb ./compton
GNU gdb (Gentoo 7.5.1 p1) 7.5.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /home/richard/git/compton/compton...done.
(gdb) set args --dbus
(gdb) r
Starting program: /home/richard/git/compton/compton -d :1 --dbus
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
^C
Program received signal SIGINT, Interrupt.
0x00007ffff6946c80 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007ffff6946c80 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff6946b3c in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:137
#2  0x0000000000415424 in cdbus_init (ps=0x629880) at src/dbus.c:32
#3  0x0000000000406e7d in session_init (ps_old=0x0, argc=4, argv=0x7fffffffe1c8)
    at src/compton.c:5815
#4  0x00000000004062ca in main (argc=4, argv=0x7fffffffe1c8) at src/compton.c:6089

Do you have an idea what's wrong?

I tried adding a sleep() to cdbus_init(), and the result is quite similar with what you saw: Movable cursor, and wallpaper only. So, this probably is a blocking condition in cdbus_init()?

[pvanek]

I found the issue origin (not that gdb - because it does not catch break signals herem dunno why).

It stays in ps->dbus_conn = dbus_bus_get_private(DBUS_BUS_SESSION, &err); forever. And based on DOCS: "This function will block until authentication and bus registration are complete." we got it.

But I have no clue why it stays here forever - I use DBUS all the time without any issue

[richardgv]

@pvanek:

Ah, I see. Doesn't catch signals? That's really weird.

Please tell me when you figure out what exactly is wrong there, if possible, so I get a little more experience. :-)

And, oh yeah, maybe someday we could go multi-threaded, to avoid blocking issues.

[DachiChang]

@richardgv

For freebsd , x11-wm/compton already send-pr to freebsd community.

http://www.freebsd.org/cgi/query-pr.cgi?pr=176480

Thanks richardgv. after some day it's will commit to freebsd ports tree. :)

[richardgv]

@DachiChang:

Thanks! :-D

[smlx]

Hi richardgv,

I've been using compton for ~9 months now, and consider it a very stable piece of software.

As there haven't been any (public) commits for a few weeks, is there any chance of tagging a release?

Thanks!

[richardgv]

@smlx:

As there haven't been any (public) commits for a few weeks, is there any chance of tagging a release?

Oh, I'm really sorry. I got a job and is no longer paying much attention to compton. (Huh, and I really don't know what to add/change.) I will fix some documentation and tag a (beta) release in a week, if everything goes well (i.e. if my cold doesn't get worse).

[richardgv]

@smlx:

Huh, sorry, a release didn't arrive on time because I changed some code, again (richardgv-dev branch). The documentation should mostly be ready, though.

[smlx]

@richardgv no need to apologise for your continuous improvements to compton! :)

I'll probably just start uploading packages anyway.

[richardgv]

Tagged. It's the same revision 7 days ago. You may wish to install bin/compton-convgen.py somewhere as well.

[hasufell]

thanks, updated

[richardgv]

New tag, v0.1_beta2: https://github.com/chjj/compton/releases/tag/v0.1_beta2

A tarball with prebuilt documentation (so that asciidoc is no longer needed, generated with make-release.sh) is attached to the release.