* gtk/src/settings.hg: Undeprecate property_gtk_cursor_blink(),
property_gtk_cursor_blink_time(), property_gtk_cursor_blink_timeout(),
property_gtk_entry_password_hint_timeout().

gtkmm-3-22: Replace Visual Studio projects with the NMake Makefiles

See merge request !6

Since the NMake Makefiles replaced the Visual Studio projects, this
commit drops them.

This adds NMake Makefiles for Visual Studio 2013 and later, which will
replace the Visual Studio projects.  The main motivation for this is to
ease maintenace on the Visual Studio build files, especially as sources
are often added or removed, making the project files out-of-date as they
are not generated during 'dist make'.  This will share the various
filelist.am's so that any additions or removal of sources can be
reflected upon the Visual Studio builds immediately.

Since this is the C++-11 version of gtkmm which supports both Visual
Studio 2015 and 2017, we want to name the DLL and .lib to be like
<library>-vc140-3_0.[dll.lib] or <library>-vc140-d-3_0.[dll|lib] since
they both link to the v140 Windows C/C++ runtime DLLs, and thus these
DLLs and .lib's are advertised to be interoperable, as supported by
Microsoft.

Note that the master branch, which requires C++-17, is not changed
as Visual Studio 2017 is really required to build things there.

Note t...

This is so that they can be used by the NMake Makefiles as well.

As a result to the move of UCRT for Visual Studio 2015 and later, some
of the CRT functions are no longer done in the CRT DLL, but are instead
implemented directly in the CRT headers.  We need to filter out these
symbols so that we can link the gtkmm DLL properly.

Unfortunately we cannot just link to legacy_stdio_definitions.lib to
resolve this, so we just have to strip these symbols out from the
generated gtkmm.def.

This prepares for the transition to NMake Makefiles for the Visual Studio
build system, which aims to reduce the likelihood of it becoming outdated
as it shares the filelist.am's with the autotools build system, instead
of being manually updated.

Don't mention the deprecated ImageMenuItem in the description.
Show the menu with accelerator keys.

Christian Schoenebeck authored Feb 11, 2018 and Kjell Ahlstedt committed Feb 11, 2018

Make sure accelator keys are shown, by calling gtk_menu_item_set_label().

https://mail.gnome.org/archives/gtkmm-list/2018-February/msg00006.html

Make the demo more like the corresponding demo in gtk+, e.g. by using
Gdk::Seat::grab() and Gdk::Device::get_window_at_position().

* gdk/gdkmm/general.[cc|h]: Decrecate Gdk::screen_width(), screen_height(),
screen_width_mm(), screen_height_mm(), flush(). They have been deprecated
in gtk+ 3.22.
* gtk/src/fontbutton.hg: Disable deprecation warnings when fontbutton.cc
is compiled. gtk_font_button_set/get_font_name() and property font-name
are deprecated in gtk+ 3.22 in favor of gtk_font_chooser_set/get_font() and
GtkFontChooser:font. They can't be deprecated in gtkmm 3.22 because
FontChooser is not a base class of FontButton.
* demos/gtk-demo/example_change_display.cc: Don't use the deprecated
Gdk::flush().

* gtk/src/cellrendererpixbuf.hg: Add a specialization for
Glib::Value<Cairo::RefPtr<Cairo::Surface>>. A specialization for
Glib::Value<Cairo::RefPtr<T>> can't be put in glibmm, because glibmm does
not depend on cairomm. It can't be put in cairomm, because cairomm does
not depend on glibmm. It's needed for property_surface(). Bug 788513

GtkObject was moved down to the GLib level, as GObject, 2 versions ago.

https://bugzilla.gnome.org/show_bug.cgi?id=788587

When gdk-pixbuf is built with meson instead of autotools, generated .h
and .c files are stored in gdk-pixbuf/build/gdk-pixbuf. Files in that
directory shall be read when the docs.xml and the .defs files are generated.

Read .h and .c files from the gtk+-3 directory.

Glib::throw_exception(GError*) takes ownership of the GError.
SignalProxy_Custom_gtk_callback() must give a copy to throw_exception().

https://bugzilla.gnome.org/show_bug.cgi?id=784483

Editable::get_chars_vfunc(), RecentChooser::get_current_uri_vfunc() and
Scale::signal_format_value() shall delete the returned character array
after it has been copied to a Glib::ustring. Bug 783360

Daniel Boles authored Jun 03, 2017 and Daniel Boles committed Jun 03, 2017

These are already defined in convert_glib.m4, which is included as-is.

https://bugzilla.gnome.org/show_bug.cgi?id=783136

There is no way that the pointer d can become null here.

including our own and those from the stdlibs. This is more idiomatic, so
it makes for better example code to show users.

Nearly 3 years later, I think we can safely assume these icons are
available on the end-user’s system.

Daniel Boles authored May 26, 2017 and Daniel Boles committed May 26, 2017

in the spirit of
https://git.gnome.org/browse/gtk+/tree/docs/CODING-STYLE#n458

“Every file must include config.h first, then its own header, then other
GTK+ headers that it needs, then system and third-party headers that it
needs.”

For the “other GTK+ headers” part, I took the liberty of using the order
I normally follow, which is GLib headers followed by GIO ones followed
by GTK+ ones. I use this as it follows their order in the software stack

int or unsigned int are not guaranteed to be wide enough. Of course,
that will not matter in many practical cases, but it is better style to
always use std::size_t when the purpose is to index into an array.

Daniel Boles authored May 26, 2017 and Daniel Boles committed May 26, 2017

The decrement was in the iteration expression, so it happened after the
loop body. So on the first iteration, this would call remove_page() with
i == get_n_pages(), which is of course 1 past the maximal allowed index.

Commit 4504487c replaced the old C syntax (void*)0 with nullptr but did
not remove this comment, which referred to the original cast expression.

Daniel Boles authored May 10, 2017 and Daniel Boles committed May 10, 2017

• typo in internal comment
• wrong claim that it always creates a horizontal Box in documentation
  comment – looks like a copy-and-paste error from the HBox/VBox days.

They included the line “This assumes that the CellLayout contains only
one CellRenderer.” But that doesn’t matter: these methods always return
the first cell, without caring whether there are any others, and thus
users can call them without caring too. So, that comment had no purpose.

Also, these are ‘safe’ to call for Layouts containing no cells, in the
sense that they will return nullptr, so we might as well clarify that.

• Fix example slots to have the correct bool return type; they were void
• Don’t use example as 1st paragraph as it ends with ;. which looks odd
• Open by explaining what the typedef is for, with link to its foreach()
• For each foreach*(), name and link to its type of slot in the comment
• Use the actual function name in each case, instead of always foreach()

Daniel Boles authored Mar 27, 2017 and Daniel Boles committed Mar 27, 2017

static_cast is better C++ style and safer due to compile-time checking.

https://bugzilla.gnome.org/show_bug.cgi?id=780004

Daniel Boles authored Mar 27, 2017 and Daniel Boles committed Mar 27, 2017

This is only useful to us if the constructor can be invoked with one
argument (i.e. it only has 1, or the subsequent have default values).
That is not true here, so the explicit keyword is a semantic mistake.

https://bugzilla.gnome.org/show_bug.cgi?id=780004

gtk_file_chooser_dialog_new_with_backend() was deprecated in gtk+ 2.14
and removed in gtk+-3. The corresponding ctors in FileChooserDialog should
have been removed in gtkmm-3.

gdk_window_process_all_updates() and gdk_window_process_updates()
have been deprecated in gtk+-3.