There are a few cases in the code where conditional compiling can
lead, when the corresponding block is not activated, to some arguments
not being used.
This patch adds the proper stuff to avoid a false report from the
compiler.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As a callback function has a fixed prototype, it is not an error to have
some arguments unused, but we need to let the compiler about it to avoid
spurious messages that would hide real cases.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The C language provides the macro 'sizeof' to handle this kind of
situation, so do not create locally a macro which can become a source
of problems.
Took opportunity to change the size of buffer to follow guidelines
from Inotify's manpage, and to remove the initial value that is useless.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
If the triggering condition occurred, the file handle for Inotify were
closed, but as the variable containing the handle was not updated it
could lead to multiple call to file close, which behaviour may be
problematic.
The file handle was passed as a parameter, which does not allow for a
clean value change, so now we use the variable directly as it is
available in the global namespace.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The XDND support is not enabled by default, and not simple to
enable (does not use the appropriate configure flag method).
With previous global namespace related patches, this file not being
enabled a change was missed. Now at least it compiles, although it
is still an experimental feature.
The default domains were originally defined in different global
variables in C files; This patches groups them in a single
structure placed in global namespace.
The variable keymove_tick is set, but is never used after, so can
be removed.
kix@osaka:~/src/wmaker/git/wmaker-crm/src$ grep keymove_tick *[ch]
moveres.c: scr->keymove_tick = 0;
screen.h: int keymove_tick;
kix@osaka:~/src/wmaker/git/wmaker-crm/src$
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
Setting a clip as autoattracting will disable an autoattracting drawer,
and reciprocally. Although not immediately obvious, it should be fairly
easy to figure out, and is totally reversible. So we'll probably never
opt to show that confirmation dialog box.
toggleAutoAttractCallback needs to check whether there are clips before iterating
through them (or it crashes WM!). The extra test is needed because now drawers can
auto-attract as well. Before drawers, only clips could auto-attract, so testing
wPreferences.flags.noclip was pointless.
The variable wapp_list is never set, then the comparison with
wapp is only true if wapp is NULL. wapp can not be NULL in the
function wApplicationDestroy() because is tested previously.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
The variable session_state, defined in screen.h (WScreen), is moved to
the global variable w_global.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
This patch gets rid of the warning:
switchpanel.c: In function 'wSwitchPanelSelectFirst':
switchpanel.c:673:18: warning: variable 'tmpwin' set but not used [-Wunused-but-set-variable]
by using the body of the WM_ITERATE_ARRAY directly and avoiding the temporary
variable 'tmpwin' which ends up being used only on the LHS inside the macro.
Because the wClipIconPaint() function is specific to paint the clip,
it knows where is the clip (wks_info.clip_icon), so the argument is not
needed.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
The appicon list is moved out of WScreen. The reason is because
the appicon list is used to create and remove icons (appicons, dock,
clip,...) on the screen, but these icons are not associated with the
WScreen. These icons are associated with the Workspace.
If we check the WWorkspace struct we can see that the Clip is inside
this struct. The dock, the background, the workspace name are other
items related to the Workspace, not with the screen.
So, we should take out the appicon from the WScreen. But, what is the
better place to hold it? The workspace? NO!, because the icon list
is common to the all workspaces. Probably the better place is hold
as independent list in the global namespace, so this is my option.
In the next patches we can see that this is the better option, because
we can create the icons, without think where we should paint them.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
The WScreen arguments in the functions wWorkspaceMenuUpdate() and
makeMakeShortcutMenu() is not used now, so can be removed.
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
The clip, dock, workspaces and drawers menus are common for all
workspaces, so they should be included in the global namespace
instead of the screen struct.
The variable workspace_menu, that contains the workspace_menu
is moved to the global workspace properties.
Now the screen is not needed to know the workspace_menu.
This variable is moved to the global workspace struct because it is
related to the workspace system, and not to the screen.
The variable workspaces, that contains the list of workspaces
is moved to the global workspace properties.
Now the screen is not needed to know the workspaces.
The function getWindowState() doesn't need the WScreen argument.
The variable current_workspace, that contains the current workspace
is moved to the global workspace properties.
Now the screen is not needed to know the workspace_count.
