There is not much room in the inspector window; squeezing a
tree and a detailed view in the same page is not great. Instead,
make the details a separate page.
We still need to possibly scan the toplevel after selecting
a widget, since we don't monitor the list of toplevels, so
the window may not be in our tree yet. This was broken in
commit e7bd73f2b0.
When closing the inspector before the main window, we must take
care to sever all signal connections and weak refs, otherwise
things will go bad when the window is closed later.
This allows us to access otherwise hidden windows, which can be
useful to provide better debug information than would be available
through other means.
https://bugzilla.gnome.org/show_bug.cgi?id=736557
When closing the application window before closing the inspector window,
the selected widget will be set to NULL once and all the property pages
will try to g_object_weak_unref that NULL widget, so bail out in
gtk_inspector_prop_list_set_object if it's NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=736201
Tools like damn-lies rely on being able to generate .pot files
from pristine checkouts, so everything that goes into the .pot
file has to be in git. This is not ideal, but we already do
the same for other .ui.h files in GTK+.
Otherwise, git.mk will add them to .gitignore, and we want to
add them to source control for the benefit of tools like damn-lies
which rely on being able to generate a .pot file from a pristine
checkout.,
What was happening that the button press event that we use
to select a widget caused another clicked signal emission of
the inspect button, starting another pick action.
gtk_css_section_get_end_position() can return a position one byte beyond
the end of the last line.
gtk_text_buffer_get_iter_at_line_index() accepts only valid
line_number/byte_index pairs. Another solution is to make the
GtkTextBuffer function less strict, by returning a boolean if the exact
position was found.
The CSS parser should also be fixed to always return valid positions.
But it's better to have a safety net in the CSS editor, just in case (a
warning could be print).
https://bugzilla.gnome.org/show_bug.cgi?id=735337
It is actually a bad idea to use noinst_PROGRAMS for build tools,
because it adds a $(EXEEXT). It is best to override the all target
with all-local to trigger the tool build.
