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.
Add yet another tab for showing information about a widget that
does not quite fit into any of the other tabs (not a property,
not style information, etc...).
For now, we show the widget state, as well as the default and
focus widget for windows.
Move the touchscreen switch to the other debug switches, and
move the hidpi spin to the other graphical controls. Since the
Visual tab is getting large, make it scroll. The General tab
is purely informational again.
Some of the features we expose can be hardcoded via environment
variables. In that case, don't confuse the user by letting them
change settings that have no effect.
We were setting the next-tab properly, but were trying to
read it off the wrong object. Now, going from a cell renderer
attribute mapping to the model, or from an action-name to the
action actually works.
The CSS editor was feeling a little sluggish, because it was
reparsing and reapplying the CSS on every keystroke. Add a small
delay, to make this feel smoother.
Like the GDK and GTK portions, use autotools scripts to generate the
complete projects for gtk-inspector as sources there seem to change from
time to time.
It might be so that this, like the a11y sources, will be referenced from
the main Makefile.am of GTK directly, but just do this so that the
projects can build properly.
When going from attribute mapping to model, it makes most sense
to go directly to the data tab, and when going from an action
name to the owner, we want to show the actions tab. Make it so.
This will hopefully help resolve the circular dependency between
libgtk linking against inspector/libgtkinspector and inspector/
needing extract-strings from gtk/.
I didn't preserve the EXEEXT decorations in this operation -
automake gave me stern warnings about it, so I just dropped them
all. Somebody who cross-builds GTK+ will have to reconstruct this.
We know the objects in a size group are always widgets, so we
can avoid hard-to-track down problems with weak references by
just cleaning up when the object gets destroyed. There is still
a chance that we show a widget as part of the group after it
has been removed, but size groups simply have no signals that
would let us avoid that.
Add a tab that shows size groups of a widget. The properties
of the size group are available here, as well as the widgets
that are part of the size group. We highlight the widgets in
the application when their row in the inspector is hovered.
In contrast to the flashing, where we blink the widget a
few times, this is explicitly turned on and off.
It will be used for indicating widgets that are part of
a size group, in the next commit.
Move away from cell editing, and use a popover instead. This makes
it easier to e.g. use a color chooser - there's just not enough room
in a cell for many things.
Much of this code is adapted from tests/prop-editor.c.
Update visual.c to use Windows themes rather than the stock Raleigh theme,
and avoid hardcoding data paths for Windows (and Mac). As the dlfcn.h
functions are only used when Python is enabled, move its inclusion there[*].
Also ensure that variables are declared on the top of the block.
[*] Python support Windows needs to be investigated, as POSIX signal
handling is used there.
https://bugzilla.gnome.org/show_bug.cgi?id=730236
The entire UI is constructed with templates, so the wrapper
constructors are never called, except for gtk_inspector_window_new,
which gets called from the GTK+ code.
Show the actions that are added to GtkApplication and
GtkApplicationWindows, as well as action groups that are
inserted elsewhere with gtk_widget_insert_action_group.
https://bugzilla.gnome.org/show_bug.cgi?id=730095
Moving the inspector into libgtk lets use reuse internals without
having to add public API for everything or inventing awkward private
call conventions.
https://bugzilla.gnome.org/show_bug.cgi?id=730095
