Rebased the branch on current master. Still works fine.

Branch has issues:

  o Create Notebook

  o Set start-action TRUE

  o Add a button to the new placeholder

  o Undo

Whole thing disappears, notebook becomes a big solid square with no placeholders or tabs, redo at this point brings the button back to the top left corner but notebook is not revived.

works fine here

pushed a new version of the branch with a fix for this issue

Much better, but still has some remaining undo/redo problems.

To reproduce:

  - Create a notebook

  - Set start-action to TRUE (placeholder appears)

  - Add a button to the new start-action placeholder

  - Set start-action to FALSE (added button disappears)

    - Notice that the button does not disappear from the inspector view
      (orphaned project widget)

  - Undo

    - Notice that the button is not re-added in the appropriate location,
      instead a placeholder returns.

In the case where a property setting can result in removing a project
widget, it is important to create a command group from the editor and
use glade_widget_delete() to undoably remove the effected widget(s)
before undoably setting the property.

This should not be too difficult, as you can take glade-box-editor.c as
an example with it's "Center Child" support, which does this properly.

(In reply to Tristan Van Berkom from comment #5)
[...]
> In the case where a property setting can result in removing a project
> widget, it is important to create a command group from the editor and
> use glade_widget_delete() to undoably remove the effected widget(s)
> before undoably setting the property.

Sorry, I meant glade_command_delete() here.

(In reply to Tristan Van Berkom from comment #5)

> This should not be too difficult, as you can take glade-box-editor.c as
> an example with it's "Center Child" support, which does this properly.

Why is this done in the editor and not in the adaptor ?

copied enough code around to make this work now, hopefully.

(In reply to Matthias Clasen from comment #7)
> (In reply to Tristan Van Berkom from comment #5)
> 
> > This should not be too difficult, as you can take glade-box-editor.c as
> > an example with it's "Center Child" support, which does this properly.
> 
> Why is this done in the editor and not in the adaptor ?

The adaptor currently does not have knowledge of creating GladeCommands, only of how to apply properties from the datamodel to a runtime object (and back). It is also responsible for creating editors for itself and it's properties - those editors strictly use the GladeCommand to modify the datamodel undoably.

A more flexible approach would be to have a signature which allows the adaptor to create commands at the request of the editors, however this is not practically possible without refactoring GladeCommand first to implement command grouping more elegantly (i.e. we would need a container type of GladeCommand, instead of the crappy glade_command_push/pop_group() API we have now which uses a static integer ID and has all commands in a flat list).

That refactor would allow for a some vfuncs along the lines of:

GladeCommand *create_add_remove_command (GladeWidgetAdaptor *adaptor,
                                         GladeWidget        *widget,
                                         GladeWidget        *child)

GladeCommand *create_add_set_prop_command (GladeWidgetAdaptor *adaptor,
                                           GladeWidget        *widget,
                                           const gchar        *prop_name,
                                           GValue             *old_value,
                                           GValue             *new_value)

Etc... allowing an adaptor to return a command which would be a literal group of the expected command plus any undoable side effects.

Even then, we would still find ourselves in situations where a user's gesture or interaction with the editors and workspace, do not equate to something that fits the API exacly, such as dragging a child widget of a GtkFixed around inside it's parent, drag/resizing a child of a GtkGrid, performing a drag and drop action to move a widget from one container to another, etc - so even if we did have a more fancy API allowing the adaptor to create the commands which effects the datamodel, it's questionable if that API would always be sufficient for the types of interactions which the workspace and editors may desire to implement.


Note also, that under regular circumstances (i.e. over a decade), the only cases where a property setting could cause a project widget to be orphaned was the GtkNotebook 'n-pages' property, which we had to hack this sort of thing for, otherwise we had used the adaptor->verify_property() vfunc to simply avoid shrinking a GtkBox's "size" or a GtkTable/Grid's "rows" and "columns" below any number which would result in orphaning child widgets. Effectively, implementing anything more fancy was not really a priority as this revolved around a couple of corner cases involving only a couple of complicated container widgets, this situation in GTK+ however is changing.


Anyway, I hope this answers your question to a degree, partly it is because priorities have been elsewhere even during active glade development, and partly it is because it's not a very obvious problem to solve.

I'll take a look at your branch again in the morning :)

thanks for the background - this stuff would be awesome to have somewhere in the glade editor or adaptor docs

Nice, the problems were all fixed.

Some problems remained:

  o Warnings triggered at undo/redo time

    This was because the old code in place assumed that the only
    valid "special-child-type" was "tab", however now that there
    are new special child types this required a string compare
    while extracting children.

    Fixed.

  o Branch was sneaking in an enabling of headerbar control
    in dialogs, which we had discussed and closed as WONTFIX
    in bug 757562

    Reverted that change from the branch.

And merged to master.