5 opacity-related bugs (& patch) about compton HOT 7 CLOSED

@richardgv I just wanted to thank you for the work you have been contributing to Compton. Can I ask, would it be possible for you to fork Compton here on GitHub and apply your patches to a development branch? If so, it might make it a little easier for others to help test your patches. Anyhow, thank you again, I appreciate the fixes you have been making.

from compton.

@corenominal:

Thanks for your thanks firstly. :-)

There's a list of my 4 pending-review patches posted so far in this issue report, if that makes your life slightly easier: #38

I'm just hesitating because forking may require me to merge changes every time chjj updates something. Well, I'm not really sure how git works... If when I post another patch (not very likely soon) the 4 remaining patches still haven't been reviewed, I will fork it (or probably add a branch?).

from compton.

@richardgv I'm no expert with github either, but from what I have seen, this seems like the most common workflow:

• fork the repository on github
• pull the repository to your local machine
• apply patch/make source changes and perform commit e.g. "Fix opacity issues..."
• push changes back to your remote repository on github
• send a pull request on github containing the commit to @chjj's repository

This way, the patches can be easily merged via the click of button. Also, others will be able to pull directly from your forked repository and help test your patches, before @chjj applies them.

Also, I have been watching the Compton development quite closely over the last few months, and as you are probably aware, @chjj has stated that he has not been able to find as much time as he would like to dedicate to it. So, I am sure he would appreciate anything you can do to help minimise the administration.

Anyhow, thank you again for your contributions/fixes, I am really looking forward to testing them :)

P.S. Did I read that @chjj has given you commit access? If so, it might be easier to pull the master repository and create your own development/testing branch, instead of forking.

from compton.

P.S. Did I read that @chjj has given you commit access? If so, it might be easier to pull the master repository and create your own development/testing branch, instead of forking.

@corenominal, Yes, I consider richardgv to be a core comitter on compton now. He has commit access.

@richardgv, I'll play around with your fixes and merge them later today.

from compton.

A point to notice: The new branch richardgv-dev has all my current pending-review patches applied and slightly modified. The commits in the branch might be more up-to-date than the patches posted on the issue tracker.

@corenominal: Yeah, you are right, posting too many patches indeed wastes chjj's time, I didn't realize. I've added a branch, as branching seems to have a number of benefits over forking: No separate issue tracker would be required; possible to merge changes locally without relying on GitHub's interface; possible to merge a specific commit instead of the whole branch via git cherry-pick; could be removed at any moment cleanly.

@chjj: Hmm, it's all put inside in the richardgv-dev branch, as you should have noticed.
+2 extra changes right now. I've got the dim inactive feature (issue #2) mostly working (in an ugly way), but there are two additional bug that I noticed so I need extra time before pushing the changes out.

Two known issues:

1. If you enable -i (inactive_opacity), compton does not apply correct inactive opacity to a window if you, say, firstly minimize it then restore with some sort of task bar.
2. After applying my patches, when I tried to launch compton in .xinitrc it made all windows disappear. It happened only once.

Update: I fixed both above.

By the way, is there a reason that nicklan's shadow blacklist patch isn't being merged? Or do you plan on writing a better implementation?

By the way 2, do you think there's a need to enable compton to parse a configuration file?

glib provides implementation for configuration file parsing and hash table (which nicklan's shadow blacklist requires, well, if there's going to be a configuration file compton may have to be prepared on some sort of data structure support, because the user might put a huge amount of things in a configuration file), although depending on glib indeed will make compton heavier.

from compton.

By the way, is there a reason that nicklan's shadow blacklist patch isn't being merged? Or do you plan on writing a better implementation?

We can merge it.

By the way 2, do you think there's a need to enable compton to parse a configuration file?

I would really like to add that. A simple plaintext file called ~/.comptonrc would be nice. We have way too many arguments as it is.

glib provides implementation for configuration file parsing and hash table

I would like to steer clear of glib. Personally, I like compton, (and originally forked xcompmgr in the first place), because it's small. glib would add so much, and if we're linking to glib for this, we might as well use glib's features all throughout the code. It doesn't seem worth it to me. We could statically link to (and include) some other smaller library, like a lib specifically for json parsing, etc. Personally, I'd be more interested in writing a very simple parser without any hash table involved. Just read the file, tokenize it, and do string comparisons to set flags on a global options struct. The config file wouldn't have to be anymore complicated than [key] [value] on each line.

Anyway, closing this issue. Thanks @richardgv.

from compton.

"...is there a reason that nicklan's shadow blacklist patch isn't being merged..."

We can merge it.

I could try to write a more flexible shadow configuration system supporting regular expressions, if I could add a dependency to libpcre. The drawback is a little speed penalty when add_win(). Necessary?

I would like to steer clear of glib. Personally, I like compton, (and originally forked xcompmgr in the first place), because it's small. glib would add so much, and if we're linking to glib for this, we might as well use glib's features all throughout the code. It doesn't seem worth it to me. We could statically link to (and include) some other smaller library, like a lib specifically for json parsing, etc. Personally, I'd be more interested in writing a very simple parser without any hash table involved. Just read the file, tokenize it, and do string comparisons to set flags on a global options struct. The config file wouldn't have to be anymore complicated than [key] [value] on each line.

A thing I would like to point out that determine_wintype() and find_client_win() should both use a BFS algorithm to search through the tree, instead of DFS, which is currently in use, for optimal performance. I believe I could write a BFS search algorithm using just recursion, but without a queue implementation it could look rather messy.

You are right, however, that let a 47K application (compiled with clang & -O3) link to a 1.3MB library file is an absurd thing.

I personally don't favor the idea of using a custom configuration parser just for compton, as:

1. There are some lightweight configuration file parsing libraries floating around. libConfuse and libconfig looks interesting, for example. Using a library parsing JSON, XML, or ini-ish configuration file should be rather easy, too. I don't see why there's a point to reinvent the wheels. Their more advanced configuration file syntax might look overkill right now, yet could be proved valuable when more features are introduced later.
2. A custom configuration file parser is much more likely to have issues than the mature third-party libraries.
3. Another lightweight compositing window manager, unagi, uses libConfuse for configuration file parsing.

from compton.