Merge lp:~mc-return/compiz/compiz.fix1030473-part3 into lp:compiz/0.9.8
| Status: | Merged |
|---|---|
| Approved by: | Daniel van Vugt on 2012-08-06 |
| Approved revision: | 3307 |
| Merged at revision: | 3304 |
| Proposed branch: | lp:~mc-return/compiz/compiz.fix1030473-part3 |
| Merge into: | lp:compiz/0.9.8 |
| Diff against target: |
75 lines (+7/-8) 4 files modified
gtk/window-decorator/cairo.c (+2/-5) kde/window-decorator-kde4/switcher.cpp (+1/-1) libdecoration/decoration.c (+3/-1) plugins/opengl/src/screen.cpp (+1/-1) |
| To merge this branch: | bzr merge lp:~mc-return/compiz/compiz.fix1030473-part3 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Daniel van Vugt | 2012-08-03 | Approve on 2012-08-06 | |
|
Review via email:
|
|||
Commit Message
Reduced the scope of the variable 'icccm_version', removed a break that can never be executed, added the variables 'frameType', 'frameState' and 'frameActions' to decor_quads_
Description of the Change
Reduces the scope of the variable 'icccm_version', removes a break that can never be executed, adds the variables 'frameType', 'frameState' and 'frameActions' to decor_quads_
| Sam Spilsbury (smspillaz) wrote : | # |
| MC Return (mc-return) wrote : | # |
> 8 - unsigned int nOffset = 1, frameType = 0, frameState = 0,
> frameActions = 0;
> 9 + unsigned int nOffset = 1, frameType, frameState, frameActions;
>
> Are these guaranteed to be assigned to something we know later in the
> function? If so, we can move them there and declare and assign them at the
> same time.
Hmm. It seems I made a mistake - Maybe cppcheck had a problem with the #ifdef.
But those variables are used only here in the function updateWindowPro
#ifdef QT_45
decor_
&mBorder, &mBorder, &mBorder, &mBorder,
0, 0,
quads, nQuad, frameType, frameState, frameActions);
So theoretically we could remove the declaration of those variables completely and simplify this to:
#ifdef QT_45
decor_
&mBorder, &mBorder, &mBorder, &mBorder,
0, 0,
quads, nQuad, 0, 0, 0);
...as those variables are not used anywhere else in this function and are always 0 anyway.
Unfortunately I am having problems convincing cmake and make to compile the KDE part of Compiz here to test it, but it *should* be okay. Please check the diff.
| MC Return (mc-return) wrote : | # |
Another question:
In compizconfig/
Investigation shows that this is correct, but it could be by design:
First we find this:
case TypeFloat:
{
double *array = malloc (nItems * sizeof (double));
then in line 296:
list = ccsGetValueList
In compizconfig/
CCSSettingValueList ccsGetValueList
int num,
CCSSetting *parent);
Q: Should we fix this and if so how ?
| MC Return (mc-return) wrote : | # |
Also in /gtk/window-
calc_button_size (decor_t *d) we can find this:
if (d->actions & (WNCK_WINDOW_
button_width += 17;
In the function static void calc_button_size (decor_t *d) button_width is first declared with
gint button_width;
then assigned the value
button_width = 0;
which could also be reduced to
gint button_width = 0;
and then button_width is increased by 17 (pixels) for respective available window actions, so if the close action is valid, it is increased by 17 points, then for the maximize/restore button if any of the window actions for maximizing and unmaximizing are available, the third button would always be minimize then and we should fix this by changing:
if (d->actions & (WNCK_WINDOW_
button_width += 17;
to
if (d->actions & WNCK_WINDOW_
button_width += 17;
| MC Return (mc-return) wrote : | # |
cppcheck also warns about this in /compizconfig/


8 - unsigned int nOffset = 1, frameType = 0, frameState = 0, frameActions = 0;
9 + unsigned int nOffset = 1, frameType, frameState, frameActions;
Are these guaranteed to be assigned to something we know later in the function? If so, we can move them there and declare and assign them at the same time.