I noticed one instance of this while looking at the code the other day,
and after a quick grep, realized it happened a *lot*! One of the many
frustrating things about the English language is that we use apostrophes
to make pretty much everything possessive *except* the pronoun "it".
In that case, we use "its". "It's" is reserved for the contraction
meaning "it is" or "it has".
We use only 1 function from this library, and it is in a case that should
be rare nowadays: displays with indexed color.
This commit makes it acceptable to compile if the library is missing.
As reported in Debian bug #922284 [1]:
As evident from the prefix, GNUSTEP_USER_ROOT is a GNUstep variable and
Window Maker should not set it. Furthemore, it has been deprecated for
12 years already. As of gnustep-make/2.7.0-4 the GNUstep build system
is configured in strict v2 mode which makes it impossible to compile
GNUstep software. In a terminal started from a Window Maker session:
yavor@aneto:/tmp/gorm.app-1.2.24$ make
This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
rm -f InterfaceBuilder; \
ln -s GormLib InterfaceBuilder
/usr/share/GNUstep/Makefiles/config-noarch.make:121: *** GNUSTEP_USER_ROOT
is obsolete. Stop.
It is also impossible to build gnustep-make from pristine upstream
source:
yavor@aneto:/tmp$ wget -q
ftp://ftp.gnustep.org/pub/gnustep/core/gnustep-make-2.7.0.tar.gz
yavor@aneto:/tmp$ tar xzf gnustep-make-2.7.0.tar.gz
yavor@aneto:/tmp$ cd gnustep-make-2.7.0/
yavor@aneto:/tmp/gnustep-make-2.7.0$ ./configure
...
yavor@aneto:/tmp/gnustep-make-2.7.0$ make
config-noarch.make:121: *** GNUSTEP_USER_ROOT is obsolete. Stop.
Note that the majority of GNUstep users use Window Maker as their window
manager and many of them build GNUstep software from source, mostly
because of the GNUstep Objective-C runtime which depends on Clang
(Debian packages use GCC and the GCC/GNU runtime).
Our solution is to replace the GNUSTEP_USER_ROOT environment variable with our
own environment variable, WMAKER_USER_ROOT. This is documented in NEWS.
[1] https://bugs.debian.org/922284
Mouse pointer can be now moved together with window if keyboard was used
for arrange maximized windows on screen. This feature can be turned on
in WPrefs.app in Expert tab by selecting "Move mouse pointer with half
MAXIMIZED windows.", or setting "PointerWithHalfMaxWindows" to "Yes" on
~/GNUstep/Defaults/WindowMaker file.
Now it is possible for change a bit pattern for changing state between
half-maximized windows. Half maximized windows will become maximized if
there is issued half-maximizing shortcut in opposite direction. Issue
half-maximizing command on same direction on already maximized window,
will have no effect.
Using MoveHalfMaximizedWindowsBetweenScreens option user can enable
ability for moving half-maximized windows not only within current
screen/head/display, but also to other heads, if they exists. Note, that
only vertically or horizontally maximized windows can be transfered to
another display. Quarter-maximized windows are not supported, since it
is ambiguous to predict in which direction such window should be moved.
These are both integer values, and thus use the new OPTION_WMAKER_INT class.
We also update the text describing the window snapping feature for
clarification and consistency.
This patch introduces two new configuration values, SnapEdgeDetect and
SnapCornerDetect, which users can set to change the distance from an edge
or corner at which window snapping will begin. The defaults are 1 and 10,
respectively.
Suggested-by: Josip Deanovic <djosip+news@linuxpages.net>
As reported by Nerijus Baliunas and Paul Jakma, the GNOME application,
which use the GTK toolkit, are asking to have no window decoration. This
can be solved by editing the window's attributes in Window Maker, but this
can be tedious when there are many GNOME application used.
This patch adds a configuration option: Window Maker tries to detect for
GTK-based windows and in this case ignore the decoration hints that were
provided by the application.
Suggested-by: Paul Jakma <paul@jakma.org>
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The name of the 2 settings have been changed:
- enable: MiniwindowApercuBalloons -> MiniwindowPreviewBalloons
- size: ApercuSize -> MiniPreviewSize
The old name is still supported to avoid breaking user's configuration, but
WPrefs will update the setting to the new names when updating the
configuration.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
This patch adds the ability to "snap" a window to the top, bottom, or any of the
four corners of the screen. It uses three new helper functions, drawSnapFrame,
getSnapDirection, and doSnap, to reduce code duplication and increase
readability.
It also updates NEWS to indicate the additional directions.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
If the new preference SwitchPanelOnlyOpen is set to YES, pressing
alt-tab or similar shortcut will only open the panel without
automatically switching to the next window. Shortcuts will continue to
function normally once the panel is open.
Users can enable the new preference if they find themselves regularly
opening the switchpanel just to visualise which windows are open, or to
initiate same-class cycling.
The default value of the new preference is NO. Behaviour is unchanged
unless the preference is explicitly enabled with the following command:
$ wdwrite WindowMaker SwitchPanelOnlyOpen YES
(Window|Menu)Title(Min|Max)Height defaults options allow to set
minimum and maximum titlebar height.
For example, to force all titlebars to 24 pixels execute
following commands:
$ wdwrite WindowMaker WindowTitleMinHeight 24
$ wdwrite WindowMaker WindowTitleMaxHeight 24
$ wdwrite WindowMaker MenuTitleMinHeight 24
$ wdwrite WindowMaker MenuTitleMaxHeight 24
Signed-off-by: Alexey I. Froloff <raorn@altlinux.org>
On Wed, Sep 15, 2010 at 04:40:52PM +0200, Gilbert wrote:
>
> "." = {NoAppIcon = Yes;};
> "*" = {NoAppIcon = Yes;};
Oh, I see. It lets you override NoAppIcon generically instead of for
each app.
> Exactly, having 'DockApp' as the class name makes them behave more
> consistently internally. This might be fixed in some other way
> internally, but I couldn't figure it out...
Except it doesn't, the only thing it changes inside wmaker is that it
avoids displaying the name as "DockApp" on the settings window.
A "dockapp" is just an application that sets icon_window in WM_HINTS
(which causes a window to be displayed as the app icon) and
initial_state to WithdrawnState (which causes the main window to not
actually appear when the window is mapped). The class has nothing to do
with it.
The problems I mentioned stem from gtk+ not allowing you to set
initial_state to WithdrawnState. Openbox and fluxbox (and maybe others)
don't take the icon_window into their "slit" unless initial_state is
WithdrawnState, so the whole thing completely fails. Wmaker always uses
the icon_window for the app icon, so that part works fine, but the
"main" app window still flashes onscreen for a split second before the
app can call gdk_window_withdraw(), and wmaker applies SharedAppIcon to
it which winds up screwing up the "Kill" menu option.
That said, I've attached a patch to have wmaker treat any window with
class DockApp as if it had initial_state = WithdrawnState, and hopefully
openbox, fluxbox, and the like will pick up the idea too so gtk+
hacks[1] will no longer be needed. If this patch is accpeted, I'll poke
fluxbox and openbox to suggest the idea to them.
[1] E.g. http://wmudmount.svn.sourceforge.net/viewvc/wmudmount/dock.c?r1=8&r2=7
Subject: [PATCH] Improve dockapp recognition
Dockapps are traditionally recognized by having initial_state =
WithdrawnState in WM_HINTS. But some toolkits (e.g. gtk+) will not allow
setting initial_state in this way. So we offer an alternative: any
window with the res_class portion of WM_CLASS set as "DockApp" will be
treated as if it had initial_state = WithdrawnState.
