This code was commented out but enabling it leads to no issues AFAICS
and improves the usability of WINGs applications.
The motivation for this patch comes from the need of distinguishing
where the cursor is in the WINGs-based application which handles the
database of my comics collection.
This changes the behavior in all parts of wmaker where there is
a text field entry, e.g. in the settings panel of dockapps. There should
be no issues with a blinking cursor in such cases though...
On 12.11.2012 Paul Seelig reported:
- open an application positioning an app icon on the bottom
- right click this app icon to show the context menu
- wonder yourself why there are two lines saying "Hide"
- first Hide entry does not do anything, second does
The reason for this curious behavior is the following.
The "Launch" entry was added in 8352c9ef60 ("Allow relaunch with shortcut key")
as the first one in the appicon menu, but this first position was hard-coded
in another part of wmaker's code in order to decide the menu entry text based
on the application's 'hidden' state in openApplicationMenu():
if (wapp->flags.hidden)
menu->entries[1]->text = _("Unhide");
else
menu->entries[1]->text = _("Hide");
But the "Launch" entry is before these "Hide/Unhide" entries and now the assumption
about entries[1] containing the relevant string for this hide/unhide decision is
no longer valid.
The simpler "fix" is to move the "Launch" entry below these "Hide/Unhide" games.
This reverts commit 824255b1ae.
According to Iain Patterson:
This patch breaks the frame extents stuff I submitted recently. With
the patch and compton set to draw semi-opaque frame extents what
actually happens is no window decorations are drawn and a bunch of
BadDrawable errors are spewed to the console.
After reverting the patch everything works again.
LITE was removed in fe736e849c ("Remove LITE config option"), but
the check for it in wmaker.inst was missed.
Furthermore, remove confusing message about wmaker being configured for KDE.
Making all in src
CC actions.o
actions.c: In function ‘wMaximizeWindow’:
actions.c:421:14: warning: ‘maximus_height’ may be used uninitialized in this function [-Wuninitialized]
actions.c:440:29: warning: ‘maximus_width’ may be used uninitialized in this function [-Wuninitialized]
actions.c:442:35: warning: ‘maximus_y’ may be used uninitialized in this function [-Wuninitialized]
actions.c:454:18: warning: ‘maximus_x’ may be used uninitialized in this function [-Wuninitialized]
CCLD wmaker
These warnings were harmless because they were at a point where
find_Maximus_geometry() had already been called. So let's simply initialize
them to zero to silence gcc.
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
We want to avoid having to consider the position of an appicon whose
application has no_appicon set. The appicon is not "painted" so it
does not appear on the screen. But if the appicon is still added to
the list of application icons, the wArrangeIcons() function gets
confused and ends up creating holes in the icon positions which
correspond to the no_appicon apps.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
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>
Function names are important and should not do more than their
names imply. In this case, create_appicon_from_dock() should only
try to get an icon from the dock (or clip).
If the icon is not there, do not try to make an icon from scratch.
You were told to create it from the dock!
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Xrandr support is currently very primitive and stupid, but people
do not seem to be aware of its problems and still enable it in distros.
Try to scare them to not do that.
This reverts commit cbe2f4e61a.
The reason for the revert is the regression reported here:
http://marc.info/?l=openbsd-ports&m=133151145814675&w=2
I've been able to reliably reproduce the double-spawning of
xterms I've been seeing. The bad news is that it still happens
even with a fresh configuration directory.
To reproduce:
0) Create a keyboard shortcut if one does not already exist (I'm
using <ctrl>+u set to spawn an xterm)
1) Open WindowMaker's preferences.
2) Click on "Applications Menu Definition" (it's the icon
immediately to the left of the keyboard icon)
3) Click save, and then close.
4) Keyboard shortcuts will spawn two applications.
I use keyboard shortcuts to spawn xterms, browsers, and filemanagers.
All of them spawn twice after performing the above. To fix it,
<F12> or <right-click> -> Exit -> Restart.
If I repeat steps 1-3, three windows will spawn. Repeat again and
four windows will spawn etc. (I stopped after getting five to
spawn at once).
There is a bug which happens when one modifies the "Initial Workspace" in the
"Attributes..." menu. Upon saving the change wmaker segfaults.
Commit ad373ef0dd ("WindowMaker: New function wGetWorkspaceNumber")
used wfree() in variables which were not wmalloc'ed. Fix this.
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 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.
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.
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>
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 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.
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()...
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>
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)
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.
This reverts commit f4890b17e6.
It turns out that I needed some functions from wtext.c to develop
a WINGs front-end to my comic book collection MySQL database.
Conflicts:
WINGs/Makefile.am
WINGs/WINGs/WINGs.h
With the addition of an extra button to the 'Advanced Options' window,
the vertical space of the widget no longer suffices. Increase it from
350 to 360 and adjust other parameters accordingly.
And let's write the button positions as 'PHEIGHT - 40' instead of using
a hardcoded value, avoiding the need to change it everytime PHEIGHT is
changed.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The flag to not let windows be minimized was already defined in
WM (it's called 'no_miniaturizable') and the minimize functions
respect it. However this flag can not currently be set manually.
As can be read in the NEWS file
"NotMiniaturizable option changed to NoMiniaturizeButton"
it seems that the "non miniaturizable" property was a first-class citizen
in ancient times and probably configurable (those changes do not appear in
the old CVS history).
Let's make this property be user-configurable through the "Advanced Options"
panel.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Before this change some lines in the "Advanced Options" window would not
fit into one line and would screw up the others. This depends on the fonts
used, but increasing the width of the panel a bit does not hurt.
Instead of using _old_ and hard-coded predefined menus as the
source for the user's WMRootMenu during installation, generate
the menu automatically using wmgenmenu.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
wmagnify stopped working after f65b99e615 ("Remove warnings").
So revert that change in util/wmagnify.c, as it turns out that the
gcc warning was bogus there.
If we Restart() directly, the windows with titlebars come back N pixels
below their original positions before the xrandr-induced restart, where
N is the titlebar height.
To avoid this issue, let's do the proper restart preparation before
actually calling Restart().
Let's also grab ConfigureNotify in the event loop as in the patch
here: http://lists.kde.org/?l=kwin&m=116429907520188&w=2
(thanks to Tamas for pointing it out).
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Some people using nvidia and/or playing some games (e.g. Einstein)
are reporting some issues with the restart induced by the
resolution changing. Let's disable it by default.
People without nvidia cards etc can still enable it with
--enable-xrandr.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
The code was added in 2001 in commit acdc0e3d6b for
"backwards compat". This motivation no longer exists in 2010,
so there is no reason to keep a private implementation of
a standard function from the C library.
Instead of using the --disable-verbose-compile hack, let's
use the standard option --enable-silent-rules (or 'make V=0' directly)
available with autoconf 1.11 and higher.
This is enabled in autoconf by using 'silent-rules' in AM_INIT_AUTOMAKE.
The verbosity of compilation is reduced in a similar manner as using
the --disable-verbose-compile option, so we can remove all that ugly
hackery.
According to the autoconf manual, using AS_HELP_STRING is recommended
to avoid having to manually adjust the alignment of help text
in ./configure --help
WUtil.h:212: warning: function declaration isn’t a prototype
WUtil.h:259: warning: function declaration isn’t a prototype
WUtil.h:300: warning: function declaration isn’t a prototype
WINGsP.h:593: warning: function declaration isn’t a prototype
WINGsP.h:599: warning: function declaration isn’t a prototype
WINGs.h:616: warning: function declaration isn’t a prototype
raster.c:295: warning: no previous prototype for ‘calculateCombineArea’
This patch makes wmaker automatically Restart() to take into account
resolution changes done by xrandr.
The motivation to write this patch is that when I start my laptop connected
to an external monitor (VGA1), the resolution in the monitor is initially
wrong (perhaps this is a bug in XOrg or OpenSuse, but anyway), so I always
do this after starting wmaker:
xrandr --output VGA1 --preferred
The resolution in the external monitor gets fixed, but wmaker does not
recognize the change automatically and I have to manually restart it.
So this patch avoids the last step by making wmaker be XRandR-aware.
Wmaker now restarts automatically when it receives a RRChangeScreenNotify
event and I don't have to do the last part of the silly procedure described
above.
I am not sure if restarting wmaker is the most elegant solution, but
it at least solves part of my issue with wmaker + xrandr.
If a window has the skip_window_list flag set wmaker currently not only skips
this window from the window list (F11) but also from the switchpanel (TAB).
This patch makes skip_window_list-windows appear in the switchpanel and be
skipped only in the window list, strictly honoring what the name of the flag
is supposed to mean.
The motivation for this is that I have lots of workspaces and almost all of
them has a xterm, so that I set the skip_window_list for the xterms not to
overcrowd the window list. But I still want to alt+TAB to xterms on the current
workspace.
In addition to that, now the "internal window" flag is not checked before
appearing in the switchpanel.
gcc-4.4.1 was complaining:
fontconv.c: In function ‘mapWeightToName’:
fontconv.c:114: warning: field precision should have type ‘int’, but argument 4 has type ‘size_t’
fontconv.c:114: warning: field precision should have type ‘int’, but argument 4 has type ‘size_t’
fontconv.c: In function ‘xlfdToFc’:
fontconv.c:157: warning: field precision should have type ‘int’, but argument 4 has type ‘size_t’
fontconv.c:157: warning: field precision should have type ‘int’, but argument 4 has type ‘size_t’
Carlos R. Mafra