Add a utility project to get config.h and gdkconfig.h from their *.h.win32
(or win32_broadway, if applicable) counterparts, using custom build rules,
so that these "generated" files can also be removed on clean and
"regenerated" upon update. This also enables the removal of configs in
certain projects that isn't really needed as a result.
Also update and merge the projects and property sheets to include a single
property sheet that it needs, which will then in turn include the other
property sheets that is needed, so that things are cleaner.
Add a utility project to get config.h and gdkconfig.h from their *.h.win32
(or win32_broadway, if applicable) counterparts, using custom build rules,
so that these "generated" files can also be removed on clean and
"regenerated" upon update. This also enables the removal of configs in
certain projects that isn't really needed as a result.
Also update and merge the projects and property sheets to include a single
property sheet that it needs, which will then in turn include the other
property sheets that is needed, so that things are cleaner.
Updates to the Visual Studio 2010 projects will follow later.
This header, which is not universally available, is accidently made to be
included unconditionally during the refactoring of gtkapplication.c,
so restore the #ifdef check.
Applications need a way to fix or adapt the decoration layout,
for situations like split header bars. Setting the layout from
the theme with a style property did not offer a good way to do
this, and the ::show-close-button property does not provide
fine-grained control.
To improve the situation, move the layout string to a property of
GtkHeaderBar which is backed by a setting. This allows platforms to
set a default button layout independent of the theme, while applications
can override the default.
The style GtkWindow style property is now deprecated and ignored.
The button now claims its menu as a child for a11y purposes,
which makes it possible for ATs to see it when the navigate
the tree top-down.
Update the a11y test to match.
We go to extra length to set the desktop_uri to NULL when
desktop == home, but then we were adding the (non-functional)
place item anyway. Don't do that.
A number of C99 math.h functions, along with inttypes.h were included for
Visual C++ 2013, along with much improved C99 capabilities, so update
config.h.win32.in to reflect this.
Fixes a tiny typo in commit f51c9d4154
which manifested itself in GtkSpinButton's panels being drawn with an
incorrect, not updated state.
This patch took me more hours than you might think! :P
https://bugzilla.gnome.org/show_bug.cgi?id=709491
The reason why some of the strings in gtkprintunixdialog.ui
were missing is that we did not extract translatable string
from <item> elements. Fix that.
gtkapplication.c has turned into a bit of an #ifdef mess over time, and
many of the current checks are incorrect. As an example, if you build
Gtk for wayland, and exclude the X11 backend, much of the functionality
required by wayland (such as exporting menu models) will be disabled.
Solve that by introducing a backend mechanism to GtkApplication (named
GtkApplicationImpl) similar to the one in GApplication. Add backends
for Wayland, X11 and Quartz, with X11 and Wayland sharing a common
'DBus' superclass.
GtkApplicationImpl
|
/--------------+-------------------\
| |
GtkApplicationImplDBus GtkApplicationImplQuartz
|
/-----------+-----------------\
| |
GtkApplicationImplX11 GtkApplicationImplWayland
GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as
hooks for various things that the platform-specific backends may be
interested in doing (startup, shutdown, managing windows, inhibit, etc.)
With this change, all platform specific code has been removed from
gtkapplication.c and gtkapplicationwindow.c (both of which are now free
of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in
gtkapplicationwindow.c).
Additionally, because of the movement of the property-setting code out
of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and
friends) will be set on non-GtkApplicationWindows, such as dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=720550
Since update_windows list is a static variable in GdkWindow.c which
contains pointers to windows which needs to be updated, it can happen
that it contains a pointer to a window even after quit from a gtk_main().
If another gtk_main() is called in the same process it tries to process
windows in the list which leads to a crash.
Correct reference count handling of added windows prevents such applications
from crash.
https://bugzilla.gnome.org/show_bug.cgi?id=711552
