Re: File dialog improvements

[Tim Janik <timj gtk org>]

On Tue, 14 Sep 2004, [iso-8859-5] °àâñÜ ¿ÞßÞÒ wrote:

> On lun, 2004-09-13 at 17:44 +0200, Tim Janik wrote:
> ...
> > > * It seems the only way to clear the project "dirty" flag (which means
> > > "unsaved" as stated in the code) is to clear the undo history with
> > > bse_project_clear_undo (get_property returns value based on undo
> > > history). This means, that undo is impossible after saving the project
> > > (generally ok, but undo after saving is even better, though not a must).
> >
> > right. undo stacks could also stay empty due to configuration options,
> > and undo stacks may be >0 although a project hasn't been modified yet
> > (that's upon activating playback). so "dirtyness" needs native support
> > by BseProject.
> >
> > > * I used the native gtk file chooser dialog, because BstFileDialog
> > > (GxkDialog) misses gtk_dialog_run (they inherit from GtkWindow, not
> > > GtkDialog), so it seems impossible [I may be wrong here] to escape the
> > > main loop for some time... bst_choice_modal failed to block the loop as
> > > well :( Besides, the new GtkFileChooser looks cooler. The chooser
> > > requires gtk 2.4, but I beleive it's ok. 2.4 has been around in many
> > > distributions already.
> >
> > what kind of loop problems did you run into with bst_choice_modal()?
> > it implements the "Overwrite: yes/no" dialog in a modal fashion.
>
> I don't remember how did I call it, but after choice_modal, there was a
> call of gtk_widget_destroy on parent dialog. And choice_modal appeared
> and disappeared immediately together with the dialog.

how did you generate a widget_destroy on the parent dialog, while
having a modal dialog popped up?
and yes, the modal dialog is popped down on purpose if it's parent
dialog gets destroyed. what point is there in e.g. asking about saving
an image that has long been destroyed?

> > i'm not sure already depending on 2.4 is a good idea. OTOH, i may have
> > tripped across the 2.2/2.4 border myself with a few recent GUI changes,
> > so i intend to test that before the next release and if necessary switch
> > over.
>
> configure.in specifies requirement even for 2.0. gtk 2.4 is alright,
> since gnome relies on 2.4. I only suffer from gtk-sharp stable being
> based on 2.2 :(

oh, that's a bug. the README already depends on 2.2, configure.in simply
doesn't appear to be updated. we have a bunch of other changes that
benefit from 2.4, so we'll probably make the move to a 2.4 dependency
with the next release.

> > > Things not implemented (yet):
> > >
> > > * Need to update merge dialog, etc.
> >
> > if you mean with regards to the file browser, then you're better off
> > converting bstfiledialog.[hc], instead of replacing it gradually with lots
> > of new selectors.
> >
>
> I don't want to add a bunch of new selectors [although I want as much
> dialogs/actions logic as possible to be moved to bstapp] Another reason

i don't want dialogs to be moved to bstapp.c. most dialogs have their
own .c files atm, and that helps maintainability a lot. besides, bstapp.c
is already too huge.

> was, that I didn't want to break things, hence the dialog is in the app,
> although could be split. Tell me, if you're going to merge the code,
> than I'll clean it up and send again.

as i outlined previously, save-if-dirty needs proper BSE support first.

> > > * Need a way to split project filename and it's path for
> > > messages/titles/etc.
> >
> > right, the full file name should be a seperate property no prjects.
>
> Not required... We can use the available property (now how it was
> called?) :) for storing full path, and separate the filename from the
> path in dialogs, notebooks, etc. when required. I think glib had such
> functions.

that doesn't work. the project name is a free form editable text field
to be defined by the user, just like synth or song names.
the actual file name is a GUI only property of a project, it could
be stored via bse_proxy_set_data().

> > > +    if (error)
> > > +      show_error_dialog (GTK_WINDOW (file_dialog), "Error opening project '%s'", filename);
> >
> > you don't need this, there's bst_status_eprintf() below (or, if you
> > want a dialog, we should prolly add that to bst_status_eprintf()).
> >
> > > +    else {
> > > +      BstApp *app;
> > > +      bse_project_get_wave_repo (project);
> > > +      app = bst_app_new (project);
> > > +      app->first_time_save_flag = FALSE;
> > > +      // FIXME: need to check if waves are included with the project
> > > +      //        and set save_self_contained flag appropriately
> > > +      gxk_status_window_push (app);
> > > +      bst_status_eprintf (error, _("Opening project '%s'"), filename);
> >
> > this already converts the error to an i18n string.
> >
> > > +      gxk_status_window_pop ();
> >
>
> Yes, I like dialogs a lot more, because I myself don't pay much
> attention to the statusbar. By the way, beast itself displays a warning
> dialog, when there's no midi device available, but a status message when
> the audio device is busy: these ones I beleive should be different :)

hm, this should be fixed with recent CVS, i.e. you should get a dialog
if playback can't be started.
disabling the MIDI device selection dialog has yet to be implemented though.

> > > * Polish strings in the new dialogs and mark them as translatable.
> > > * For the "save unsaved file?"-dialog to satisfy hig requirements 100%,
> > > there must be label with time passed since last save/creation.
> >
> > note that i don't agree 100% with the hig. for beast,
> > 	http://beast.gtk.org/wiki:UsabilityGuidelines
> > takes precedence over the GNOME hig, it's prolly a good idea to
> > follow the hig for things unspecified in UsabilityGuidelines though.
> >
> > > * The "warning: file changed" and "replace file?" dialogs need markup
> > > (again for hig).
> >
> > what do you mean with "markup"?
> >
>
> the gmarkup... when you call gtk_[label | message_dialog |
> etc. ]_new_with_markup, you specify text in a simple markup language.
> like:
>
> "<big>File was changed. Save?</big>" (displayed in larger font)
> "if you click no, changes will be lost" (displayed in common size)

hmmm. how does that relate to other dialogs? should all text be switched
to <big> then, unless it's explanatory remarks? and if not, why
is this question bigger than anything else?
that is, i'd like to see a consistent rule for changing text sizes
across the whole of the GUI, before i start to mark up individual
dialogs.

> Artem
>

---
ciaoTJ