Merge lp://qastaging/~3v1n0/bamf/wmclass-matching into lp://qastaging/bamf/0.4
Proposed by
Marco Trevisan (Treviño)
| Status: | Merged | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Merged at revision: | 387 | ||||||||||||
| Proposed branch: | lp://qastaging/~3v1n0/bamf/wmclass-matching | ||||||||||||
| Merge into: | lp://qastaging/bamf/0.4 | ||||||||||||
| Diff against target: |
488 lines (+198/-40) 3 files modified
src/bamf-application.c (+50/-3) src/bamf-application.h (+6/-0) src/bamf-matcher.c (+142/-37) |
||||||||||||
| To merge this branch: | bzr merge lp://qastaging/~3v1n0/bamf/wmclass-matching | ||||||||||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Jason Smith (community) | Approve | ||
|
Review via email:
|
|||
Description of the change
Now bamf uses also the window WMCLASS parameter and the .desktop file StartupWMClass to associate a window to its application.
This causes that each bamf application should now have its own class; a window is considered as part of that application only if its wmclass matches the application one.
A desktop file is now associated to an application also considering the StartupWMClass key value.
To post a comment you must log in.
Revision history for this message
| Mikkel Kamstrup Erlandsen (kamstrup) wrote | # |
Revision history for this message
| Marco Trevisan (Treviño) (3v1n0) wrote | # |
Preview Diff
[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
I am not sure I'm the right person to review this branch, but I got one nitpick nontheless :-)
The get_class() and set_class() methods on BamfApplication are not very binding friendly. If I called app.get_class() from Vala or PyGI it would normally give me the GObjectClass struct for the object, but this patch would override that method.
Maybe get/set_wmclass() instead?