2008/1/27, Eero Tamminen <eerot@users.sourceforge.net>:

On Sunday 27 January 2008, Benny Malengier wrote:
> 2008/1/26, Eero Tamminen <eerot@users.sourceforge.net>:
> > Sorry, could you explain the problem a bit more?
> > Clicks to a window go to only that window, not to other windows?
> Ok, start gramps, open person editor, from there open event  editor, from
> even source editor.
> Now drag the windows so the ok buttons are all visible next to each
> other, and then with the mouse quickly click on ok of person, ok of
> event ok of source.
> If quick enough the ok method will start on all tree dialogs, running
> over each others (eg callback of event goes to person editor, but person
> editor is first window so it's ok will close the event editor, ...).

IMHO the windows should be either independent or they shouldn't. If they are
independent, they are non-modal, if they are dependent, they are modal. If
some windows are modal, preferably all windows should be modal or at least
their tranciency has to be set such that the modal dialog cannot be lost
below the other windows (as it prevents interacting with them).

I.e. either the window opened from another is modal, or it's non-modal and
the other window doesn't affect its lifetime at all.  As in Gramps all/most
dialogs are non-modal, it might make more sense in this case if the windows
were left open even when their parent is closed (they shouldn't then be even
trancient), but I don't know how hard that would be to do if the (database)
objects they manipulate can be changed (deleted) by their parents.  In
that case a modal window would probably be more appropriate.

If the path how user ends up with an object (a window) dictates how the
state/life-cycle of that object handled, and you can arrive at and exit the
object through multiple paths at the same time, that way lays madness
(uncontrollable code behaviour).

> The above is what we want to design out: clicking ok disables the
> possibility of clicking ok on another window for the duration of the
> save. A progress modal dialog can do that trick. So can disabling events
> for the duration of the save (but application appears as you say broken
> ).

Well, using a modal dialog is about same as disabling events, the other
windows don't react.

(dialog_run() creates it's own mainloop so events to other windows are not
processed, but Gtk takes still care of handling their expose events).

All good points, but I think the way gramps works is one of it strong points, making the windows modal would not be work-flow friendly (they are transient already though).
Thanks for info.