Behaves essentially the same, only a bit more consistently.
Known differences:
1. An AppIcon will now always end up undocked if moved while Mod1 is pressed.
2. Moving a docked AppIcon with Mod1 pressed (undocking it) used to auto-expand the clip,
as clip expansion happened first, while looking for a snapping position,
and the test on Mod1 being pressed happened only later
The options are ClipAutoraiseDelay, ClipAutolowerDelay, ClipAutoexpandDelay, ClipAutocollapseDelay
The default values are weird but merely represent the previously
hard-coded ones. They are repeated in Defaults/WindowMaker to avoid a
WPrefs crash (but it's a good idea to make them "visible", too)
WPrefs change coming up
In handleIconMove, when moving an appicon near the clip, all clips were
systematically shown each time the mouse moved, causing some flickering
(perhaps only perceptible on a low-end machine?). This patch introduces
a showed_all_clips boolean to expand clips only once.
If btn->omnipresent, then btn->dock is precisely
scr->workspaces[scr->current_workspace]->clip (cf.
wWorkspaceForceChange() calling wClipUpdateForWorkspaceChange())
The call to wIconUpdate() can be changed by call to update_icon_pixmap(),
because the icon doesn't need to be changed. This update is only for change
the icon pixmap to un-shadowed.
Now, the icon pixmap is updated faster.
The call to wIconUpdate() can be changed by call to update_icon_pixmap(),
because the icon doesn't need to be changed. This update is only for change
the icon pixmap to un-shadowed.
Now, the icon pixmap is updated faster.
The call to wIconUpdate() can be changed by call to update_icon_pixmap(),
because the icon doesn't need to be changed. This update is only for change
the icon pixmap to shadowed.
Now, the icon pixmap is updated faster.
The call to wIconUpdate() can be changed by call to update_icon_pixmap(),
because the icon doesn't need to be changed. This update is only for change
the icon pixmap to shadowed.
Now, the icon pixmap is updated faster.
This patch avoid a crash when moving an icon without command.
To reproduce the problem:
1. Launch an application, for example xeyes, with appicon.
2. Move the appicon to the clip.
3. Close the application.
4. Edit the appicon in the clip, and empty the commands fields.
5. Move the appicon from the clip to the dock. -> Crash.
The crash happends because icon->icon->owner is NULL and then
wwin will be NULL. Then the call of wwin->client_win will crash.
This patch checks if icon->icon->owner is not null (application is
running) and then assign it to wwin. Then get the command from the
running application.
The function wIconUpdate can receive a image to setup as icon image.
If image is NULL, then use the original method, using different procedures
to get the image.
The line "icon_editing = 0" is the first line in the "if" sentence
and the first (and only) sentence in the "else" block, so can be
moved outside the if-else (and the empty else block can be removed).
This patch reviews the code style in dock.c, removing some
curly brackets not needed and adding other where needed.
This patch removes some lines commented and some extra lines for
better understanding.
The functions of main.c should be included in main.h, not in funcs.h.
This patch adds the main.h file and moves the function prototypes to
this file.
The not needed "include funcs.h" are removed.
Create a header file dockedapp.h to address a long-standing warning
which pollutes the compilation output with --enable-silent-rules:
Making all in src
CC dock.o
dock.c: In function ‘wDockDetach’:
dock.c:2118:3: warning: call to function ‘DestroyDockAppSettingsPanel’ without a real prototype [-Wunprototyped-calls]
dock.c:65:13: note: ‘DestroyDockAppSettingsPanel’ was declared here
CCLD wmaker
Having two similarly named functions for doing the same thing is confusing.
In order to account for the extra check done by the late wAppIconSave(),
add an argument "dock".
Now there's only save_appicon().
And as pointed out by Rodolfo kix García, the save_appicon_core() function
can be removed too.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
memset is the last function call in wmalloc, just before it returns the
newly allocated memory. Therefore it is not needed to call it again
after wmalloc call. Although I would prefer to switch wmalloc to a
calloc-based wcalloc function, the compatibility of WINGs for old apps
should be kept.
Changes to appicon.h:
- Spaces replaced by tabs in the struct
- Removed unused variables:
- client_machine, never assigned
- gnustep_app, never used
- Functions sort by return type
Then, in dock.c, the block with client_machine is never true,
then can be removed. The host variable then is never used.
The only place where this function is called is from a double click
in the first icon of the dock, and only if there's no program already
associated with it.
This is a bit superfluous and most people have defined the first
icon to call WPrefs instead and end up never seeing that panel.
And since the last commit ("Change behaviour of the GNUstep dockapp"),
this is now also the default behaviour of Window Maker.
Furthermore, the panel itself is not accurate. Window Maker is not part
of the GNUstep project.
When the mouse passes over the clip, wmaker would display a "odd" balloon
text with the workspace name, but the balloon itself was covered by the
clip icon!
So if the workspace name was short enough ("Internet" is, by my testing here)
the user wouldn't see anything, the balloon is completely under the clip icon.
I found this issue because one of my workspaces is called "Beyonder" and I
noticed a small "r" under the clip one day.
Instead of trying to fix this, I just removed the whole thing about displaying
the balloon because it is superfluous and I haven't seen any bug reports about
this yet, so it probably means most people are not even aware of it.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
GRADIENT_CLIP_ARROW was never defined anywhere and having fancier clip
arrows is not something particularly interesting, so let's simply remove
the code.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
I use xrandr to decrease the resolution of my display when I connect
it to my TV. When I change the resolution back to my monitor, a few
of the icons at the bottom of my dock are deleted.
This happens because wmaker computes the maximum number of dockapps
which the dock can hold based on the screen resolution:
icon_count = scr->scr_height / wPreferences.icon_size;
and drops the dockapps above that number (in wDockRestoreState()).
But now the resolution can change via xrandr, so the above computation
can lead to dockapps being dropped when the new resolution is smaller
than it used to be.
To fix this it's enough to have a resolution-invariant number of allowed
dockapps.
PropGetWMClass()
- XAllocClassHint()s a struct for class hint data
- This is filled by XGetClassHint(), which in turn uses Xlib to allocate
some more space for XClassHint members
- Upon XGetClassHint() failure, "default" is libc malloc'd (via strdup),
and is returned to the caller
- Upon XGetClassHint() success, XClassHint members are returned raw --
these members must be freed with XFree() (see XAllocClassHint(3))
- Thus it's up to PropGetWMClass() callers to decide (based upon the return
value) which method (libc free() or XFree()) to use to free res_name
and res_class. This was done nowhere, thus leaking some memory
on every failed PropGetWMClass() call.
- So just strdup the successful res_name/res_class members, XFree() them
while still in PropGetWMClass(), and allow callers to unconditionally
libc free() whatever PropGetWMClass() returns.
* Remove assigned but not used variables (GCC 4.6)
* Bump _XOPEN_SOURCE to 600, ridding of FreeBSD warnings (this probably need
to be tweaked on a per-implementation basis as problems arise)
There is little point caching a pixmap for an app that isn't in the
dock. This patch creates a function wAppIconSave that saves only if the
app icon is docked, and adds calls to that function in all the places
where an appicon can transition from undocked to docked.
It also "adds" a function wApplicationSaveIconPathFor that saves an icon
path to the configuration plist; the function already existed, it was
just static before.
Signed-off-by: Brad Jorsch <anomie@users.sourceforge.net>
It addresses this warning
dialog.c: In function ‘LoadHistory’:
dialog.c:209: warning: passing argument 2 of ‘WMFindInArray’ from incompatible pointer type
../WINGs/WINGs/WUtil.h:455: note: expected ‘int (*)(void *, void *)’ but argument is of type ‘int (*)(const void *, const void *)’
but induces others in other places. One of them was this one
window.c: In function ‘wManageWindow’:
window.c:782: warning: passing argument 2 of ‘WMFindInArray’ from incompatible pointer type
../WINGs/WINGs/WUtil.h:455: note: expected ‘int (*)(const void *, const void *)’ but argument is of type ‘int (*)(void *, void *)’
which is fixed by constifying the arguments of matchIdentifier(). The other warnings are
fixed similarly.
Two reasons for removing it:
1) I won't ever want to hear useless sounds
2) The sound support is a bit of a joke. The code is there but you have
to hunt it somewhere else (not in any repository that I know of).
In my 10 years of using wmaker, I never used it for this reason.
Now I consider having no sound in Window Maker a feature, and I like
it that way. So there is no point in carrying useless code around.
PS: There is still the code in WPrefs to be removed.
