We really want margins around the scrollable content, not around
the viewport. Make it so by using textview-specific properties.
This is unfortunately a little complicated for top/bottom.
"Hey I know, let's do an easter egg!"
"What kind of easter egg?"
"We can nest lots of textviews!"
"Sounds cool!"
...
"But how does one see a textview inside a textview?"
"What do you mean?"
"Well, it just looks like black text on a white background."
"You mean it's the same as if we just duplicated the text?"
"Yeah!"
"Hrm, maybe we can put a frame around it."
"Sounds good. I'll stuff the textviews in a GtkFrame."
"What? Why? Let's use a GtkEventBox and override its background"
"Why is that a good idea when we have GtkFrame?"
"Because I said so!"
"Okay."
Overriding the background color for a color swatch is wrong. The color
is not the background, it's the foreground, so it should be painted in
a draw signal handler.
GtkSidebar behaves internally much like GtkStackSwitcher, providing a vertical
sidebar like widget. It is virtually identical in appearance to the widget
currently used in GNOME Tweak Tool.
This widget is connected to a GtkStack, and builds its own contents as a
GtkListBox subclass, using the "title" child property to provide a consistent
navigatable widget.
Being a subclass of GtkListBox it benefits immediately from strong keyboard
navigation, and minimal changes are required for theming.
https://bugzilla.gnome.org/show_bug.cgi?id=735293
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Loading a builder file with a window leaves a ghost behind, since
windows need to be explicitly destroyed. Avoid that by using
gtk_builder_add_objects_from_resource.
Add rows with buttons and checkboxes to the listbox example
on page 2, and make the switch in row 1 toggle selection mode,
to test various cases of widgets in 'selected context'.
... for displaying resources. Instead use the proven and way more
reliable method of trial and error.
It's less code and more portable for a start.
But most of all it displays PNM files as text if you fail to compile
the gdk-pixbuf loader for it.
As a noinst_PROGRAMS, the libtool generated for cross-compiling will be
used, which will mess up the linking. Create a all-local target instead.
Also ensure that building uses always a native version of the tool by
specifying a GTK_UPDATE_ICON_CACHE automake variable.
Finally "config.h" has been created to work for the target platform and
causes problem when cross-compiling. So we temporarily generate a basic
config.h which contains only the strict minimum.
Change the initial value to something that is not a multiple of 3, so
that dismissing the notification on reset makes sense. Let's use 50
because that is already being used elsewhere.
https://bugzilla.gnome.org/show_bug.cgi?id=734614
Instead of slavishly following the naming spec, group the icons
into categories that are more likely to be useful for application
developers. Based on input from Allan Day and Jakup Steiner.
