With the changes to the layout, which were introduced in the
previous patch series, and the correction of the default font
size, the Legal Information panel was too small to display the
complete text.
It has been set to a sufficient size.
The names of the macros and the local variables that they use
have been changed to make them less "user-space" like.
ScaleX -> WMScaleX
ScaleY -> WMScaleY
fw -> wmScaleWidth
fh -> wmScaleHeight
The scale factors in the macros were based on the assumption that
the default font size was 11. But the actual default font size is
12. This value is specified as DEFAULT_FONT_SIZE in
WINGS/configuration.c.
Instead of just assuming that the size of the system font has not
been changed by the user, the WMCreateAlertPanel,
WMCreateInputPanel and WMCreateGenericPanel functions now use a
fixed default font size of 12, so that changing the system font's
size in WPrefs.app does not break the fixed layouts of these panels.
("12" is specified as DEFAULT_FONT_SIZE in WINGS/configuration.c)
To prevent breaking applications depending on the static layout
behavior of the WMCreateAlertPanel and WMCreateInputPanel functions
in WINGs, the scaling functionality has been moved to the new
functions WMCreateScaledAlertPanel and WMCreateScaledInputPanel.
The system dialogs (wMessageDialog, wExitDialog, etc.) now use the
new functions, thus keeping the improved layout introduced in the
previous patches.
Instead of relying on static pixel values for position and size of
the widgets, the info panel now scales its widgets based on the
selected system font size.
Instead of relying on static pixel values for position and size of
the widgets, the legal panel now scales its widgets based on the
selected system font size.
Instead of relying on static pixel values for position and size of
the widgets, the icon chooser panel now scales its widgets based
on the selected system font size.
Instead of relying on static pixel values for position and size of
the widgets, the input panels now scale their widgets based on the
selected system font size.
Instead of relying on static pixel values for position and size of
the widgets, the alert panels now scale their widgets based on the
selected system font size.
To reduce code duplication the ScaleX and ScaleY macros have been
moved to WUtil.h. Along with the function WMGetScaleBaseFromSystemFont
these macros can be used in all panels to scale the widgets based on
the current system font size instead of giving fixed pixel sizes which
messes up the panels if a larger system font is selected in WPrefs.
Use the macros in the following way:
instead of WMResizeWidget(widget, 128, 64);
WMMoveWidget(widget, 32, 32);
use int fw, fh;
WMGetScaleBaseFromSystemFont(scr->wmscreen, &fw, &fh);
WMResizeWidget(widget, ScaleX(128), ScaleY(64));
WMMoveWidget(widget, ScaleX(32), ScaleY(32));
Instead of relying on static pixel values for position and size of
the widgets, the DockAppSettingsPanel now scales its widgets based
on the selected system font size.
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.
When building into another directory than in the source, the hard-coded
relative path to the changelog will fail finding the file, causing an empty
date in the generated file when '@today' is used.
This patch is making sure the ChangeLog is taken in the source directory to
avoid any problem.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
It looks like the original code was expecting the side effect of specifying
a length in the %d to smartly truncate the number, which it does not.
The new code has the same behaviour without extra complexity.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
This kind of things participates in memory fragmentation, so it is
generally a bad practice when an on-stack allocation is enough.
Took opportunity to reduce the buffer size, there's no point in
overallocating memory (the new size being still way too much).
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
Hard-coding a value is prone to errors when maintaining the code; using the
builtin C macro 'sizeof' is a much safer choice.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
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
In 2013 Daniel added the functionality to wrap icons, which are
attached to the dock, around the screen edges when the dock is
being moved vertically.
This patch adds an expert option to WPrefs.app for setting the
property which enables/disables this feature.
Remark: In my opinion, the default value for that property should
be changed to NO, as this is also the default behavior in
NeXTSTEP. It is handy to be able to move all these icons
out of sight when working with maximized application
windows.
If the option "Enforce icon margin" is selected, application window
icons will be selected or scaled so that they only use 75% of the
available icon_size.
Even if the feature is not enabled, this change will scale down
large application icons to icon_size, so that icons can be used
that were rejected by the previous implementation of findBestIcon.
(Example: The Qt Creator icon never showed before, because it is
only provided in 128x128 resolution. Now it's visible.)
The current findBestIcon function usually selects an icon image
that almost completely fills up the (default) 64x64 pixels of an
icon. As Dan noted in the function, the icon images should use only
75% of the available space, which would result in room for the
miniwindow title and better overall aesthetics.
This feature option provides for enabling such an automatic "icon
shrinking" functionality.
Note: This commit only introduces the new option, not the actual
image shrinking.
To make some room for an additional icon option (yet to be committed)
the options group for selecting the iconification animation is
replaced by a popup button. This allows for adding at least two more
checkboxes in the options and makes adding new animation styles less
painful.
When opening the "Icon and Initial Workspace" panel of the Attribute
Inspector, the Miniwindow Image and the corresponding text field were
always empty, even if an icon had been selected, applied and saved
before. The file name was not loaded from the database on startup
of the inspector window.
With this change, the icon and the text field are properly set on
startup of the inspector window.
Window Maker allows to perform practically all operations with windows
using only keyboard. One of the actions so far which required using
mouse was dragging window from one head (monitor) to another.
This patch introduces support for keyboard shortcuts. These shortcuts
move windows in circular fashion (if you have 3 and more monitors).
In case of 2 or 3 monitors arranged horizontally - window will just move
right/left.
In case of 3x3 setup - it is impossible to move window to central
monitor with keyboard.
- preserves window position and size (if display sizes are same)
- otherwise tries to fit window to smaller display
The variable set by PKG_PROG_PKG_CONFIG which points to the pkg-config
utility is PKG_CONFIG, not PKGCONFIG. The latter was previously used
when trying to detect the presence of the MagickWand library when Window
Maker was built using --enable-magick.
The problem - when VirtualBox starts virtual machine, window has very
small height (couple of pixels) and it requires some manual fiddling
to resize it to something usable.
See related bugs here:
https://www.virtualbox.org/ticket/14718#comment:19 - small horizontal
line in the middle of the screen is newly opened virtual machine's
window.
https://www.virtualbox.org/ticket/15863
Inspecting with xdebug and xprop reveals that VirtualBox sends wrong hints:
Request(12): ConfigureWindow window=0x0660000a values={x=27 y=559
width=720 height=65512}
Which is interpreted by X server wrongly and shown with xprop as
WM_NORMAL_HINTS(WM_SIZE_HINTS)
:
user specified location: 27, 559
user specified size: 720 by -24
program specified minimum size: 254 by 109
window gravity: Static
Some part of X11 interprets such large value as signed int and wraps
it to negative value.
The solution will be if program requests such big window - detect it,
ignore requested size and resize it to some reasonable defaults.
Disclaimer - I tested it only on Ubuntu 16.04, but should apply to
another systems as well - see bug reports.
This option had been broken for several reasons:
* The getstyle utility does not replace the #usergnusteppath# macro which
was passed to it by the menu.
* When processing the USER_THEMES_DIR macro, the menu inserts a space
afterwards, and so the directory and filename were passed to getstyle
as two separate arguments.
* It used the old, pre-0.50.0 theme format.
By using the -p option to getstyle, we can avoid these issues, as we don't
need to specify the directory *and* it uses the 'new' (since 1999) themepack
format.
Fixes the bug where if the icon image is accidentally set to
nothing or the image file is deleted, the appicon keeps losing
its icon (it resets to the default cube icon) when Window Maker
exits/restarts (depending on how the user cleared the icon this
may persist even after redocking the application if information
about the application window is still in the WM). One way to
easily see this bug is to open the main window's attributes and
press the Save button (no need to do anything else) as this
clears the icon file (this is a separate bug that needs to be
fixed but it is more of a minor UI bug since clearing the image
should simply reset the icon to the application provided one if
the Ignore client supplied icon is not set). Another way to
see it is to open the properties box in a docked application
that is not running and clear the image field. After either of
these two actions are performed, restart Window Maker and see
that the icons are missing.
This patch fixes the above bug by calling save_appicon when the
appicon object is created and the application provided icon is
already available (window maker actually tries to save the icon
at an earlier stage but this is done as a side effect of
"painting" the dock icon - which also saves the icon - but this
is done too early, before ownership information is available).
Note that this bug seems to be a regression introduced from
commit 9c4b19d8aa (or one of the
related commits around the same time, they seem to be a bit too
aggressive in not saving icons). This patch addresses the
concern in that commit about only saving the icon for docked
applications.
This adds an option (IgnoreDecorationChanges in plist) for windows to
ignore any requests from the clients for changing decorations. Since the
default state for any window pre-request is to have all decorations visible
this basically means that applications cannot hide any of the titlebar,
sizing bar, titlebar buttons, etc and any hint that causes these elements
to be hidden will be followed by a restoration if this option is set.
This is useful for broken clients (e.g. Steam) and clients that force
subpar client side decorations. It is basically a per-window setting of the
global advanced option to ignore Gtk hints, except that it also applies to
non-Gtk applications.
in order to make builds reproducible. See
https://reproducible-builds.org/
for why this is good.
This date call works with GNU date and BSD date. Without this patch,
/usr/share/doc/packages/WindowMaker/README.i18n will differ in the
line An alternative solution could use the $SOURCE_DATE_EPOCH
variable defined in
https://reproducible-builds.org/specs/source-date-epoch/
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
There was a typo in background.menu. Although the menu worked fine, it
caused these errors in the logs:
wmaker(WMReadPropListFromFile(proplist.c:1543)): error: error reading
from file '/usr/share/WindowMaker/Backgrounds'
Compacting two translations to fit the available space; two new strings.
The menus are now split like the English ones, using appearance.menu.fy
and background.menu.fy. A new comment was added to menu.fy.in.
Compacting a translation to fit the available space; two new strings.
The menus are now split like the English ones, using appearance.menu.nl
and background.menu.nl. A new comment was added to menu.nl.in.
Inspired by the Debian patch 54_Debian_wmmacros.diff. These macros are
actually already referenced in appearance.menu and background.menu, but
only Debian installations have taken advantage of them.
We use the new #usergnusteppath# macro to reference the user GNUstep path.
This macro is used when handling directories with OPEN_MENU, e.g., to list
available image files for setting the workspace background.
When parsing a menu file, we replace any instances of #usergnusteppath#
with either GNUSTEP_USER_ROOT or ~/GNUstep if the former is not set. In
this way, authors of menu files do not have to worry about whether users
will have this variable set or not.
We also document this feature in WindowMaker/menu.in, which generates the
default English language old-style menu and currently contains the existing
documentation for the Window Maker menu system.
We remove the macros LOCAL_THEMES_DIR, LOCAL_STYLES_DIR,
LOCAL_ICON_SETS_DIR, and LOCAL_BACKGROUNDS_DIR.
They were only referenced in the Debian patch 54_Debian_wmmacros.diff, which
set them to /usr/local/share/WindowMaker/{Themes,Styles,etc.}.
In a default installation, THEMES_DIR, STYLES_DIR, etc. coincide exactly
with these paths. In a Debian installation (which defaults to /usr/share
instead of /usr/local/share), it seems unlikely that a user would have these
files in both locations.
