In its current state, the patch can hang Octave or fail on errors about non existing objects, e.g. when running "demo text" and pressing Return repeatedly to run the next demo fast. This looks like threading issues that must be fixed prior to integrating the patch, and I don't currently have the time either to dig seriously and validate the current code. Maybe someone else will jump in and give his opinion.

>> May be it will be easier when the graphics toolkit code get correctly splitted from the GUI code (they are still tightly coupled by things like base_qobject and similar...)

AFAICS, jwe is currently restructuring the code base so that the GUI can be started from a cli session in a tty:

https://octave.discourse.group/t/new-command-window-widget/501

So I think we indeed better wait a bit.

> * the inspector should be able to live without the GUI running, at least I'd be very happy if that happened :-). Since your inspector window inherits octave_dock_widget, that makes me suspect that the inspector won't run without the main window running. Am I wrong?

With an intermediate container, that should not be the main problem to solve. The main problem (for me at least), is that I have no clue how works the code in the QtHandles namespace.

> * we already have a mechanism to notify the graphics toolkit when graphics object properties change and at first sight you seem to have re-engineered another independent one. Maybe your approach is better (and we know the current mechanism is sometimes fragile), and it could be merged, but it would be better to not have multiple functions for the same task.

I agree with this. I didn't intend my code to work without the GUI, and it lives outside of the graphics toolkit.
I currently don't have a grasp on the QtHandles namespace code and how it connects to the interpreter.

BTW this makes me think that I currently don't listen to properties change (only to object creation/deletion). I will add this.

I attached a new patch with binary data included.

What I meant is two-fold:

• the inspector should be able to live without the GUI running, at least I'd be very happy if that happened :-). Since your inspector window inherits octave_dock_widget, that makes me suspect that the inspector won't run without the main window running. Am I wrong?
• we already have a mechanism to notify the graphics toolkit when graphics object properties change and at first sight you seem to have re-engineered another independent one. Maybe your approach is better (and we know the current mechanism is sometimes fragile), and it could be merged, but it would be better to not have multiple functions for the same task.

> I merged all the patches into a single one for convenience (attached).

Thank you. There is a PNG icon somewhere in the diff (look for hsplitter-handle).
Unless I am missing something, the mercurial diff format do not include the binary content.
My patch-5 included it with the git diff format.

diff --git a/libgui/src/icons/hsplitter-handle.png b/libgui/src/icons/hsplitter-handle.png
new file mode 100644
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..3247c8d0a32ec0d2218c47458f2dab026310e61f
GIT binary patch
literal 147
zc%17D@N?(olHy`uVBq!ia0vp^tUzqe!3HFc+--0MQk(@Ik;M!Qe1}1p@p%4<6riAF
ziEBhjaDG}zd16s2LwR|*US?i)adKios$PCk`s{Z$Qb0uto-U3d7QM+C85uv$A2@KJ
p!B1FBBGhtKQOMI3US6S03^%JI+IDe-uK}uM@O1TaS?83{1OV(+EHnTB

> Could the inspector be untied from the main GUI?

If this means moving the code to libgui/graphics folder, yes that is easy.
I guess the "inspect" function would be trivial to implement from there.

This indeed looks like a very useful piece of work. I merged all the patches into a single one for convenience (attached).

I didn't look at the implementation yet but I have a first remark: I am a terminal user and I'd definitely vote for having access to the inspector without the need of the GUI, trough the currently missing "inspect" function [1]:

https://www.mathworks.com/help/matlab/ref/propertyinspector.html;jsessionid=158c0e3dc5e515b88f0d6ecc55f8

Could the inspector be untied from the main GUI?

Maybe it could be integrated in the Qt graphics toolkit, where all the logic of graphics property updates is already in place?  
If so take a look at the discussion here:

https://octave.1599824.n4.nabble.com/Removing-init-qt-dependency-on-libgui-td4698367.html

Yes, patch 5 is on top of 4.
I did a hg pull between 4 and 5. Although I was careful not to merge what I pulled into my changes, it may have an impact on the patch application. In addition, patch 5 is made in the git format because there's a binary file (splitter handle image).
May be you need to apply with a git option? I'm not familiar with Mercurial.

I don't see the handle image on your screenshot, may be it is from patch-4 level?

Regarding your last remark, I had the same impression of complexity. I was thinking to add in the tree a column with text that identifies the object. For this I need to map each type of object with a property that is relevant for the user. (e.g. the figure title, the axes title, the menu text...)
For some objects there won't be anything to display, but it may help to navigate in this tree.

A step further is to have the graphics objects selected/highlighted in the figure itself. This goes way beyond the property inspector. There is a lot to do on this side! (selecting, moving, editing objects in the figure)

Thanks Remy, you're quick!

patch #5 on top of patch #4 or instead?

FTR, this afternoon I made a Windows build incl. patch #3; works nice.
I'll try patch #4 later this weekend.

Some notes:

• I undocked the P.I. and closed the pane. After restarting Octave and setting visibility of the P.I. to "on" in the main menu it doesn't show up at all. "Reset Default Window Layout" in the main menu gets it back. So restoring an undocked P.I. across Otave sessions needs a bit of attention.
• There are no shortcut for the P.I. pane (I'd suppose it could be Ctrl-7 & Ctrl-Shift-7).
• There's no tab in the Preferences pane for the property inspector.
• Maybe row height can be made a little lower? (that's what I was searching in the Preferences pane).

> In the mean time buiding a Windows binary failed.

This seems to be me introducing a HANDLE enum symbol, which is already defined as an opaque pointer on Windows.
I think it is the same for BOOL and CALLBACK.

The 3rd patch should fix this. (I can't build on Windows myself to check)

Works nicely in Linux (building for Windows now).
I never realized that a simple plot of sin(x) has so many uimenus.

After playing around with it I think this is a very useful tool. I'm often struggling to find out what property belongs to which handle/child and then how to adapt it. This tool presents a nice overview. Thanks for creating this.

In the mean time buiding a Windows binary failed, partial log attached. As it compiles fine on Linux I suppose this is an mxe-octave issue.


(file #50301)

Attached patch-2 which should work at least up to Qt-5.12 (I didn't check older).
5.12 is the last LTS version (before 5.15 released this year).

The second patch applies over the first one. I'm very new to Octave development so I'm not sure of how you review the code, but it seems easier that way. I can collapse everything together at your convenience.

> Looking at the patch, have you hard-coded all properties for all objects?

There is no hard-coding. My code uses

graphics_object::get_properties ().all_property_names ()

in the table model constructor to get the properties to display.
Then each property is displayed/edited according its type.

Similarly, the tree uses the parent and children properties and it doesn't need to know anything about the graphics objects.

So this is very generic already.

Thanks for the patch, but same issue for me as in comment #1. shrunkBy was introduced in Qt 5.14. and may used platforms to build oct() ave have older Qt versions installed. Could you please replace this code line by a workaround that works with older Qt 5 versions?

Initial implementation of Property Inspector


HIGHLIGHTS

  * a widget with two main views
    - a tree to display and interact with graphics object tree
    - a table, displaying the properties of the object selected in the
      tree

  * the tree receive notifications of graphics object creation/deletion
    to update itself

  * the table provides display and edition of most types of properties


SHORTCOMINGS

  * Not all property types have yet proper editors/painting

  * Updating properties does not always reflect in the figures.
    - updating line color for example not always trigger redraw.
    - when redraw happens, all previous property editions are visible

  * No link to help is provided. 2 possible strategies:
    - compute URL to online help from handle type and property name
    - embed the help in the executable. I have no clue how to do this.


DETAILED CHANGELOG

  * liboctave/util/oct-mutex.h
    - adding unique_lock template class that encapsulate a critical resource
      providing lock/unlock methods. unique_lock is moveable but non-copiable
      and also acts like a smart pointer.
      - not a strictly needed addition, but is used to provide safely the
        gh_manager instance to the GUI

  * libinterp/corefcn/graphics.in.h
    - adding some introspection of graphics properties
      - prop_type() method (returning new property_type enum)
      - as_base_property() method to retrieve a pointer that can be casted
      - as_[type]_property() that dynamic_cast the base property to derived
        type (not used - compiled out at the moment)

  * libinterp/corefcn/event-manager.h
    - adding lifetime events of graphics objects in the interpreter events
      interface. Needed to track creation and removal of graphics objects in
      the tree.

  * libinterp/corefcn/graphics.cc
   - fire the graphics objects lifetime events

  * libui/src/qt-interpreter-events.h
  * libui/src/qt-interpreter-events.cc
    - adding signals for the new graphics objects

  * libgui/src/interpreter-qobject.h
  * libgui/src/interpreter-qobject.cc
    - provide access to the gh_manager through a unique_lock
    - the GUI cannot use the gh_manager without locking it
    - Not very useful today because the gh_manager is not consistently locked
      in the interpreter thread (e.g. when setting/reading properties).
      This could lead to race conditions (although I didn't observe any).
    - May be a better strategy is to have fine grain (per property) locking.

  * libgui/src/property-inspector.h
  * libgui/src/property-inspector.cc
    - implementation of the property inspector
      - simple widget that instantiate the more complex views and models and
        make them talk together

  * libgui/src/property-inspector-tree.h
  * libgui/src/property-inspector-tree.cc
    - implementation of the graphics handle tree model
    - quite straightforward Qt tree model code

  * libgui/src/property-inspector-table.h
  * libgui/src/property-inspector-table.cc
    - implementation of the graphics properties table model and item delegate.
    - to keep code flexible, I tried to take the best decisions based on the
      octave_value of the property rather than based on the derived property
      type, but this is not always possible. (hence the properties
      introspection)
    - there (at the moment) two specific widgets used as cell editors:
      - matrix_widget
      - color_editor_widget (this one use a *.ui designer file)

  * libgui/src/property-inspector-color-editor.ui
    - Qt Designer file for the color_editor_widget

  * libgui/src/main-window.h
  * libgui/src/main-window.cc
  * libgui/src/gui-preferences-sc.h
    - instantiate the property inspector and setup shortcuts

  * libgui/src/module.mk
    - adding new property inspector files