Re: Redesigned initial dialog

[Armin Burgmeier <armin arbur net>]

On Sun, 2008-03-30 at 20:27 +0200, Murray Cumming wrote:
> On Sun, 2008-03-30 at 16:24 +0200, Armin Burgmeier wrote:
> > I just committed a first version of a redesigned initial dialog to Glom
> > trunk. There is a screenshot at [1]. It is currently very similar to
> > Murray's proposal [2].
> >
> > I think that it would be better, UI-wise, to only use one treeview for
> > both types of actions. Normally, you are only interested in either
> > opening an existing document or a new document (but not both), so you
> > need only one of the views anyway.
>
> Maybe a notebook would be a good solution.
>
> >  But when you resize the dialog, to
> > view more items at once, half the space is wasted for the other
> > treeview. If all actions were in a single treeview, then you would only
> > expand the branch you are interested in, giving all extra space to those
> > items.
> >
> > The actions already make clear enough whether they open an existing
> > document or create new one, IMHO.
>
> I'm not convinced. I think it's good to make it very clear what will be
> the creation of a new document and what will be the opening an existing
> document. The examples need this extra hint, because they start creation
> instead of just opening.

The examples are in the "New From Template" section which already
indicates that they create something (rather than opening it). Anyway, I
think a notebook might be a good solution as well.

> I think I would like to add a [Select] button to the right of [Close],
> which would do the action on the selected row in the selected treeview,
> because it's hard to know that I can click on those row buttons.
> [Select] is not ideal, but it's better than [Create or Open depending on
> what you clicked on].

> And the dialog should close as soon as something has been clicked. I
> don't think that the dialog->run() ever returns at the moment, and I
> don't think that the response is really used.

The response is used to determine whether the user clicked Close to exit
the application. Perhaps it would be a better approach to provide
methods that return the document to open instead of the current signals,
as GtkFileChooserDialog does. This way, the dialog also could easily be
hidden directly after having been run.

Armin