It was removed on 67a8a82670 with the assumption that
nothing was using it. But that was not really the case - FSViewer
used it.
I've just tested it. After a trivial fix regarding the change in
the function definition of WMWritePropListToFile(), FSViewer
compiles and even seems to work (didn't test much though).
So let's not be unfair with FSViewer and put wmlib back. FSViewer
might even be used for educational purposes for people wanting to
write apps using WINGs etc.
The path /etc/X11/WindowMaker is not needed now. The files were
deleted or moved to /usr/share/WindowMaker. Some files were the
same in /etc/X11/WindowMaker and /usr/share/WindowMaker.
The configuration file menu.hook is moved to /etc/GNUstep/Defaults
Duplicated:
- wmmacros
- appearence.menu (copied & generated).
- background.menu
Removed:
- menu.prehook
- menu.posthook
Moved:
- menu.hook (generated).
I have noticed that in WindowMaker 0.95.2 application icons bounce
when some actions are done, like starting a program, etc.
Disabling Superfluous or Animations also disabled the minimizing
animation which I am used to, so doing that didn't do the job.
Everyone has got his or her own tastes, but I did not like the new
behavior and didn't find any way to disable it without affecting other
things.
So I made a patch to fix just that. It adds a new option in WPrefs.app's
Expert Tab called "Do not make AppIcons bounce" which when enabled,
disables any type of bouncing for Application Icons, restoring the
old behavior.
Bouncing stays the new default behavior.
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.
Make it launch WPrefs instead of displaying GNUstep information.
GNUstep information under a dockbutton is unneeded and it's commonly replaced
by WPrefs. This also is giving one extra space for another dockapp.
WMCreateFont() was calling exit() if it could not create the
font, and was trying too hard not to return NULL.
Just return NULL if the font could not be created instead of exit()ing
and let callers decide what to do upon failure.
Thanks to Christian <chris@computersalat.de> for reporting this.
Icons in the switchpanel are constrained to the value of the IconSize
preference but the grid in which they are arranged is fixed at 64 pixels.
If IconSize is less than 64x64 the panel will show smaller icons with a
wide spacing, which looks pretty stupid.
Fix it by forcing the switchpanel to attempt to load images at the size
it's going to use. The icon it actually gets may of course still be
smaller.
Display a standard Window Maker balloon with the workspace name when the
mouse enters the clip area.
This complements commit 4954d4df23 ("clip: Do not display balloon with
workspace name") because now the balloon which appears on the clip is the
same as in other parts of wmaker.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
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>
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>]
