When setting the lines property, the label will be ellipsized
to that many lines, with the ellipsis only appearing in the
last line. This is different from how ellipsization of multi-line
labels normally works in GTK+.
I'm currently working on porting view::FieldEntry (from libview) to C for use in
upstream GTK+. FieldEntry is a widget which allows users to enter structured
text such as IPv4 addresses or serial numbers. The way that FieldEntry
delineates the fields within the entry is with tabstops, using PangoTabArray
entries to precisely position the fields and delimiters. Because GtkEntry
rebuilds its internal PangoLayout fairly frequently, this requires a property in
the entry that will set the tabs on the layout whenever that happens. This API
looks very similar to one in GtkTextView.
Patch by David Trowbridge <trowbrds@gmail.com>. Updated for Gtk+ 3.10.
https://bugzilla.gnome.org/show_bug.cgi?id=697399
... to make it possible to insert rows in the middle of the list without having
to fiddle with the sort functions. One of the first users is going to be Glade.
https://bugzilla.gnome.org/show_bug.cgi?id=705558
Add a boolean property that controls whether a window close button
will be shown in the header bar or not. Doing this in the toolkit
will ensure consistency of the visual apperance.
https://bugzilla.gnome.org/show_bug.cgi?id=702971
We rename the gtk_widget_class_bind_template_child{_internal}
macros by appending a _private to their name. Otherwise, it
would be too magic to pass the 'public' names as arguments,
but affect a member of the Private struct. At the same time,
Add two new macros with the old names,
gtk_widget_class_bind_template_child{_internal} that operate
on members of the instance struct.
The macros and functions are inconsistently named, and are not tied to
the "template" concept - to the point that it seems plausible to use
them without setting the template.
The new naming scheme is as follows:
gtk_widget_class_bind_template_child_full
gtk_widget_class_bind_template_callback_full
With the convenience macros:
gtk_widget_class_bind_template_child
gtk_widget_class_bind_template_child_internal
gtk_widget_class_bind_template_callback
https://bugzilla.gnome.org/show_bug.cgi?id=700898https://bugzilla.gnome.org/show_bug.cgi?id=700896
Add a new example to the getting started part of the docs. The focus
of this example is on 'new stuff': GtkApplication, templates, settings,
gmenu, gaction, GtkStack, GtkHeaderBar, GtkSearchBar, GtkRevealer,
GtkListBox, GtkMenuButton, etc.
It is being developed in several steps. Each step is put in a separate
directory below examples/: application1, ..., application8. This is a
little repetitive, but lets us use the code of all examples in the
documentation.
We should mention that newly written code should not have the private
data pointer in the instance structure, and that private data should be
added using the new GObject macros.
https://bugzilla.gnome.org/show_bug.cgi?id=702996
Currently you can only set the current filename, but not
get it. It's useful to be able to get it in save
dialogs, where the user has typed the desired filename
and you are not in a real directory (recent used, for
example).
https://bugzilla.gnome.org/show_bug.cgi?id=702497
I notice that a reference to GtkStrengthBar had been left in this file
when it was renamed to GtkLevelBar. On closer inspection, it looks like
it's been unused for 13 years. To quote docs/reference/ChangeLog:
> 2000-10-23 Havoc Pennington <hp@redhat.com>
>
> [...] Removed objects_grouped.sgml from gtk-docs.sgml for now, it
> doesn't seem useful anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=700575
Rename our internal GActionMuxer, GActionObserver and GActionObservable
classes and interfaces to have names in our own namespace.
These classes were originally intended for GIO but turned out to be too
special-purpose to be useful there, so we never made them public API but
have just been copying them around (without bothering to properly rename
them). Now that other people will be copying them out of Gtk, it's even
more important to prevent this namespace abuse from spreading further.
Newer versions of GCC/binutils must have the source file come before the
preprocessor and linker flags on the compiler command line, and this is
also compatible with previous versions.
https://bugzilla.gnome.org/show_bug.cgi?id=680241
This commit implements the needed machinery for GtkWidget
to build it's composite content from GtkBuilder XML and
adds the following API:
o gtk_widget_init_template()
An api to be called in instance initializers of any
GtkWidget subclass that uses template XML to build it's components.
o gtk_widget_class_set_template()
API to associate GtkBuilder XML to a given GtkWidget subclass
o gtk_widget_class_automate_child()
API to declare an object built by GtkBuilder to be associated
with an instance structure offset and automatically set.
o gtk_widget_get_automated_child()
API for bindings to fetch a child declared to be automated by
gtk_widget_class_automate_child(), for the case where bindings
do not generate GObjects under the hood and cannot use structure
offsets to resolve composite object pointers.
o gtk_widget_class_declare_callback[s]()
Declare static functions to be used in signal callbacks from
a given class's template XML
o gtk_widget_class_set_connect_func()
API for bindings to override the signal connection machinery
for a given GtkWidget derived class.
In preperation for composite objects, for better encapsulation
the following APIs are added to allow handling of signals declared
in the XML with callbacks declared statically.
o gtk_builder_add_callback_symbol[s]()
Adds a symbol to the internal symbol hash
o gtk_builder_lookup_symbol()
Looks up a symbol, exposed in case added symbols are used
in conjunction with gtk_builder_connect_signals_full()
The default implementation of gtk_builder_connect_signals() now
does not have a strong requirement on GModule (or a strong requirement
on symbols being declared in the global namespace). Instead GModule
is used as a fallback in the case that symbols are not declared
explicitly.
It's more logical to have the GtkTextAttributes and GtkTextAppearance
structs together. And it creates a separation between gtk_text_tag and
gtk_text_attributes functions.
https://bugzilla.gnome.org/show_bug.cgi?id=697048
