This starts to establish the structure for an in-place rewrite of WINGs. An
actual redesign of WINGs may follow, but for now there are no plans to alter the
structure of WINGs substantially.
We can reduce the WMNotification API surface area further by getting rid of
WMCreateNotification and WMPostNotification. WMNotification remains a
first-class object, but it is no longer possible for client code to create a
notification object directly. Notifications must now be posted through
WMPostNotificationName, which handles notification creation and destruction on
its own.
This will simplify the notification lifecycle and make the Rust rewrite
simpler. (Notifications no longer need to be reference-counted, heap-allocated
objects that might be saved somewhere after they are dispatched.)
WTextField code which reused the WMNotification struct has been modified to take
parameters of the correct type directly, instead of through a WMNotification's
void* data field.
These functions were added to glibc 2.38, so we don't even need to check for
libbsd. There isn't a strong need to worry about supporting older systems
because use of these functions should go away as we rewrite string.c in
Rust. And, apparently, they are not held in high regard historically. That's at
least 2 reasons to be rid of them.
This fixes a lot of memory bugs which arose as a result of doing something
different from the system malloc/free when allocators were rewritten in Rust.
These changes originate from a different approach to writing the allocator in
Rust:
https://git.sdf.org/vitrine/wmaker/pulls/1/files#diff-04a0fd2319b9969373b75377716e45c836d22869
There are other function calls (to XFree) that need to be fixed, but that can be
done in another commit. This one is already getting large.
This tweaks the hashtable API, and it is incomplete because the WUtil proplist
impl depends heavily on a feature of the old API that is being discontinued.
Moving the proplist code into Rust is our next objective.
While this large change has some unit tests, it has not been integration tested
thoroughly. Removing the global case insensitivity flag may be an issue in
particular.
A few of PropList API functions have been modified (mostly to get rid of
varargs). The definition of one such function has been left in C for cleanup
later.
This is not a bug-for-bug reimplementation, and it may need some shaking down to
ensure that everything still works. Once their dependents are ported, it would
be appropriate to dispose of them.
This is necessary because we now allocate memory through a special allocator of
our own on the Rust side. Passing raw malloc'd pointers to wfree will break
things.
* "unknow" -> "unknown"
* "occured" -> "occurred"
Remove some entries from PO files where these entries contain spelling errors
and there are other entries that are identical except for these mistakes.
Signed-off-by: Jeremy Sowden <jeremy@azazel.net>
This patch adds sr.po files to Makefile.am files throughout the repository
where needed. It also adds credits for Serbian localization in README files as
needed.
Signed-off-by: Страхиња Радић <contact@strahinja.org>
This patch adds a new Central feature under the window menu
"Other maximization" entry.
Shortcut can be configured via WPrefs "Center active window" action.
When called the active window is centered on the screen head.
If the window height or width are bigger than the head size,
the window is resized to fit.
There are some transitions defined as below:
*from fullscreen to center
*from any corner to center
*from top half to center top half
*from bottom half to center bottom half
*from left half to center left half
*from right half to center right half
Undoing the action is done via the window menu "Unmaximize" entry
or the shortcut.
That patch is fixing some Actions entries that are not sorted properly.
One is using some upper/lower cases.
And the other one, is displaying numbers while alphabetic sorting is not
working properly on numbers. For example:
Shortcut for window 1
Shortcut for window 10
Shortcut for window 2
...
Align the old maximization descriptions to the new visual indicator
names. The internal shortcut names had also been updated, meaning a
reconfiguration of the shortcuts in WPrefs is required.
This patch adds a feature to take screenshots directly from Window Maker.
Having the feature embeded direclty inside Window Maker allows us to take
advantage of how Window Maker is managing and handling Windows.
Three new actions can be bound to a key shortcut from WPrefs.
The screenshot files are saved in ~/GNUstep/Library/WindowMaker/Screenshots/
dir, with a "screenshot_%Y-%m-%d_at_%H:%M:%S" format followed by the
extension. Preferably as a PNG or JPG file if available.
Meaning, to work Window Maker via WRaster needs to support
at least one of those format.
"Capture the entire screen" is quite standard, it takes a screenshot
of the whole screen area (even in multiheads env).
"Capture a portion of the screen" requires the user to draw a rectangle which
will be captured.
Those two first are quite straightforward, just taking a live picture of
the screen.
The last one is "Capture a window" which works in best effort mode,
it catures the focused window. As Window Maker by default is not using
any compositor (like for example Xcompmgr) it can only dump the content
displayed on the screen.
If a window is minimized or out of the screen, there is high chance the
image will be split or some area greyed in case other windows overlapped it.
On window maker built without libxpm, a simple build-in xpm support is used.
That component does not support X11 color name thus when trying to load
that image we are getting a file corrupted error.
Colors manually converted using ref at
https://www.ehdp.com/methods/x11-colors/x11-colors-rgb-values-05.htm
Replace calls to wusergnusteppath() which just append "/Library" by calls
to wuserdatapath().
Take opportunity to replace hardcoded "/WindowMaker" directories with
the existing PACKAGE_TARNAME macro (which comes from autotools).
The choice of 'TARNAME' is because it meant to be used in filename, thus
less likely to have problematic characters than PACKAGE_NAME (meant for
display purpose) and PACKAGE which is there for historical reason.
For the Menu edition tab, when building the path to the file that contains
the menu data, rely on wdefaultspathfordomain instead of constructing the
path with many hard-coded names.
It seems there have been changes in the way Pango's header files are
installed in recent versions, probably to allow having multiple versions
together on a system.
Because one public header from WINGs has to include Pango's header, we must
include the search path provided by Pango into our WINGs search path that
are returned by pkg-config (the .pc file).
They are then also added to WindowMaker and WPrefs which use the header but
can't rely on the path from the .pc file which has not been installed yet.
Reported-by: Carlos R. Mafra <crmafra@gmail.com>
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
The header "wraster.h" needs different behaviour depending on whether the
support for X Shared Memory extension was enabled or not; but the related
macro USE_XSHM is defined by WindowMaker's configure. After this header
have been installed, the macro is no more useable.
This patch makes the "wraster.h" a generated file, so it will be different
depending on USE_XSHM, but will not make use of the macro itself.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported by Coverity (CID #50047, #50048), if the proplist is incorrect
and has an OPEN_MENU or (SH)EXEC command without its arguments, we did
dereference a NULL pointer.
Now we simply return the NULL value, appropriate to have the caller of the
function issue a message.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported by Coverity (CID #331571), we did not check the return value of
the call to XParseColor. If the function is given a colour name that it
does not know, we would return an uninitialised colour.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
