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>
Replace the ARROWLESS_KBD #define with the ViKeyMenus preference.
When ViKeyMenus is TRUE, users can type h/j/k/l to scroll around menus.
Since ARROWLESS_KBD was previously undefined by default, ViKeyMenus is
FALSE by default.
As reported by Paul Seelig, it used to be the case that
getstyle -t ~/GNUstep/Library/WindowMaker/Themes/somefile
would save the current theme, and all old menus (WMRootMenu) were
relying on this.
The problem was that the following piece (from commit 6bf79945)
if (style_file && !make_pack)
print_help(0, 1);
would allow a style_file to be specified and saved to only with the
option -p (which implies make_pack), therefore saving a theme with
-t like the root menu used to do no longer worked.
Now things work fine:
[mafra@Pilar:~]$ ls GNUstep/
Applications/ Apps/ Defaults/ Library/
[mafra@Pilar:~]$ getstyle -t ~/GNUstep/theme
[mafra@Pilar:~]$ ls GNUstep/
Applications/ Apps/ Defaults/ Library/ theme
But also note that trying to save a theme outside of GNUstep/
is not allowed and it prints no error message - perhaps it should...
In commit e1453087f57... the function copy_file() was renamed to
wcopy_file(), then the symbols file needs to be updated.
The changelog includes a new debian bug closed.
...in order to avoid clashes that happen during compilation of
wmakerconf.
This is a new function in WINGs, so renaming it at this point is
not a big deal.
Thanks to Rodolfo García for the heads up.
This upload includes the debian changes of 0.95.0 and 0.95.1
- Debian stuff (themes, menus,...) is moved to different folder.
- Many changes in debian/rules file
- New files to avoid lines in debian/rules (new menu files)
- This is a little extract form the debian/changelog file:
* New upstream version 0.95.1
* The WINGs's file proplist-compat.h is removed in upstream.
- Removed the line in debian/libwings-dev.install
* Updated debian/libwutil2.symbols with new symbol.
* libpng12-dev dependencies changed to libpng-dev. [Closes: #648123]
* wterm package suggestion removed.
* Menu shows "Run..." option. [Closes: #165075]
Thanks to Andreas Tscharner for their patch.
* Menu shows the background files [Closes: #655122]
* Added patch 54_Debian_wmmacros.diff.
Based on changelog: Marcelo E. Magallon Tue, 17 Nov 1998
* Xterm and WMPrefs are now Debian specific.
* Added patch 53_Debian_WMState.diff.
Based on changelog: Marcelo E. Magallon Sun, 26 Nov 2000
* Fix wmaker-common dependencies. [Closes: #654668]
* Manpages moved from wmaker-common to wmaker (Lintian problem).
* Removed old stuff in wmaker.post* and wmaker-common.post* about
update-alternatives.
* Fix to the FTBFS. [Closes: #654524]
* New debian/watch file
* New upstream version 0.95.0, now from git. [Closes: #401900]
[Closes: #514438, #607550, #218110, #583734, #105351, #549157]
[Closes: #283610, #311563, #310285, #329783, #280819, #284048]
[Closes: #292391, #361241, #364290, #148370, #287459, #122076]
[Closes: #175503, #79598, #78088, #68381, #38184, #41434, #41434]
[Closes: #94960, #39543, #63265, #69499, #94446, #77488, #329783]
Thanks to Andreas Tscharner for their bug revision.
* This new version is based in wmaker-crm a wmaker fork, because
wmaker (original) is not updated.
* New debian/rules file. [Closes: #590244]
* Many many changes
* /usr/lib/WindowMaker/WindowMaker is now /usr/lib/WindowMaker/wmaker
* wmaker script launch now /usr/lib/WindowMaker/wmaker
* New maintainer. [Closes: #632875]
* New package wmaker-common (arch independent files).
* Removed the asclock diversions from the wmaker install scripts
wmaker.postrm and wmaker.preinst because asclock binary is not
included in wmaker package (see asclock package).
* New package wmaker-common with the arch independent files.
* debian/patches are now DEP-3.
* debian/copyright is now DEP-5.
* Bumped Standars-Version 3.9.2.
* Manpages moved to upstream.
* Solved problems with .la files (lintian clean).
* libwmaker0-dev isn't included, because was removed in upstream.
With the fonts I use here, the memory information line in the "Info panel"
did not fit inside the window. So make that line a bit shorter by displaying
Total memory allocated: 2600 kB (in use: 2182 kB)
instead of
Total allocated memory: 2600 kB. Total memory in use: 2182 kB.
Furthermore, the surrounding code was a bit convoluted to display either
"Additional support for: WMSPEC"
or
"Additional support for: WMSPEC and MW"
As WMSPEC is always present and it doesn't seem we are adding more stuff
to support, one can do the same with a shorter code which reads a little
bit better.
Despite having the inotify mechanism compiled in my WM, everytime I
changed a keyboard shortcut definition in the WMRootMenu via WPrefs
I was required to open the WMRootMenu (eg with the F12 key) for the
change to take effect...annoying.
So explicitly reload the key bindings when a modification inside
~/GNUstep/Defaults/ is detected. As the inotify mechanism calls the
function wDefaultsCheckDomains() when that happens, let's add a call
to rebind_key_grabs() in there.
Now it works fine and changes are automatically in effect once WPrefs
writes the menu.
PS: rebindKeygrabs() renamed to rebind_key_grabs()...
The function captureShortcut() is implemented in both files KeyboardShortcuts.c
and Menu.c, with just a minor difference regarding the conversion to upper case.
To unify them, define a new function which includes a new boolean paramenter to
dictate whether the upper case conversion should be done or not.
There's no need to have a private function while there's one in WINGs.
Besides that, it does not remove trailing whitespaces appropriately as I
just tested by adding trailing space in the shortcut captured by WPrefs.
It is not trimmed before saving it:
[mafra@Pilar:Defaults]$ grep CloseKey WindowMaker
CloseKey = "Mod1+C ";
Using wtrimspace() fixes that and even saves 208 bytes of code:
[mafra@Pilar:WPrefs.app]$ size KeyboardShortcuts.o.*
text data bss dec hex filename
7703 0 0 7703 1e17 KeyboardShortcuts.o.new
7911 0 0 7911 1ee7 KeyboardShortcuts.o.old
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
There is code duplication with the cropline() function, so get rid
of it and use WINGs wtrimspace() instead.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
On my PowerPC Debian Squeeze System, the icons are colored
incorrectly. This patch removes the swapping of the data on Big Endian
systems, thus causing the icons to be colored correctly.
The data appears to already be in the native endian format.
After using WINGs wInputDialog() to handle renaming the workspace
upon Ctrl+left click on the workspace menu, all functions in src/text.c
become unused.
As pointed out in the comments in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304480
it's not possible to rename workspaces with non-ascii characters -- more
precisely characters which require deadkeys with your particular keyboard.
According to the investigation made by Rodolfo Peñas:
http://lists.windowmaker.org/dev/msg02529.html
the fundamental issue behind this bug is the fact that XLookupString can't
handle deadkeys.
So either we do something radical or live with the bug.
However -- as Rodolfo also pointed out -- renaming the workspaces via the
Clip works with non-ascii chars. The reason is that the Clip uses a input dialog
function from WINGs to handle the renaming.
So instead of doing the low-level handling of text inside the menu in order
to rename workspaces, just fire up the same WINGs input dialog to handle it.
It works and the old function editEntry() can be removed.
Furthermore, it makes the whole set of functions in src/wtext.c useless, and
they are removed in the next patch.
Overall, 600 lines of code are gone now.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The summary now looks like:
Window Maker was configured as follows:
Installation path prefix : /usr/local
Installation path for binaries : /usr/local/bin
Installation path for libraries : /usr/lib64
Installation path for WPrefs.app : /usr/local
Supported graphic format libraries : XPM PNG JPEG TIFF builtin-PPM
Antialiased text support in WINGs : yes
Xinerama extension support : yes
XRandR extension support : yes
Translated message files to install : None
I want to see the library line in order to avoid forgetting that
I should put them in /usr/lib64 (and not in the defaul /usr/local/lib)
There are some problems in the alpha channel support, as is
reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=72917
This patch add a new RCombineAlpha function, based on Gimp. This
function is called when needed in the raster.c functions.
This patch is based on the Brad Jorsch <anomie@users.sourceforge.net>
patch for the 0.62.1-0.1 version.
[crmafra: v1 was sent by Rodolfo kix Garcia <kix@kix.es>]
The statement under "if (style_file)" in the else branch of
"if (make_pack)" will never be executed because getstyle already
prints out a help message and exits before that.
So remove that code.
Instead of using a temporary buffer to store a "reason" string
which is later printf()'ed by abortar(), use wwarning() directly
and do the small cleanup done by abortar() on the spot.
As this was the only call site for abortar() it can now be removed.
The resulting object code gets smaller as a side effect.
Thanks to Christophe <christophe.curis@free.fr> for finding a mistake
in the first version of this patch.
This is essentially the fetchFile() from wcolorpanel.c from the last
commit, but renamed to a better name.
This patch just adds the function to the lib. Nobody uses it yet.
The idea is to use the fetchFile() in getstyle.c and in wcolorpanel.c
instead of using two very similar functions.
In order to do that, let's move the most generic one (fetchFile()) to
libWUtils, and this is the first step.
Dario Niedermann reported on 27.11.2011:
Selecting "Save Theme" from WMaker's root menu results in dialog box
asking for theme name, but then nothing is saved.
This feature used to work in 0.92.0.
and the reason for it (if he uses a WMRootMenu generated by wmgenmenu) is
the incorrect use of the option "-t" instead of "-p" to getstyle.
Furthermore, let the invocation of getstyle reflect the new default location
for the themes.
When invoked as
getstyle -p NewTheme
Instead of saving the theme inside the topdir ~/GNUstep let's save it
insinde their proper directory ~/GNUstep/Library/WindowMaker/Themes.
There is a problem with getstyle invoked with no arguments:
[mafra@Pilar:util]$ ./getstyle
Usage: getstyle [-t] [-p] [-h] [-v] [file]
or with -t:
[mafra@Pilar:util]$ ./getstyle -t
Usage: getstyle [-t] [-p] [-h] [-v] [file]
In both cases it is supposed to write to the standard output:
[mafra@Pilar:wmaker.git]$ getstyle -h
Usage: getstyle [-t] [-p] [-h] [-v] [file]
Retrieves style/theme configuration and output to FILE or to stdout
This regression was caused by commit 6bf7994520 ("style Stuff up").
When that commit did
argc -= optind;
if (argc != 1)
print_help(0,1);
it excluded the output to stdout as valid, because in this case
argc - optind is zero (see the manpage of getopt(3)).
The correct handling is to set the style_file only when there is
one non-option ARGV-element (argc - optind == 1) and print the
help message when there are more than one non-option element.
Applying patches without needing to fix them first helps me save time,
and this file (stolen from the linux kernel documentation) contains some
valuable tips to configure email clients to not mangle the patches you send.
The goal is that patches are sent in the body of the email (to ease review)
and be applied directly with 'git am'.
I personally use mutt as mail client and xjed as an editor. I insert the patch
in the body of the email using xjed's "Insert file" menu operation. That
works fine, but this documentation file helps you with more choices.
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.
If you delete the file ~GNUStep/Defaults/WMRootMenu and run WMPrefs
and go to the Menu Edit tab, it will show a dialog about keeping the menu or
discarding it. If you discard it then WPrefs shows an error:
"Could not open default menu from
'/home/user/GNUStep/Library/WindowMaker/plmenu"
The problem is at WPrefs.app/Menu.c:1424, and it happens because it tries
to load the default menu from the user's GNUstep home, but plmenu is not
copied there during the installation.
Of course, the file doesn't need to be copied to the users home, so
WPrefs should try to read it from /usr/share/WindowMaker/plmenu (Debian)
or /usr/local/share/WindowMaker/plmenu (upstream).
