Re: File dialog improvements

[Tim Janik <timj gtk org>]

On Wed, 8 Sep 2004, [iso-8859-5] °àâÕÜ ¿ÞßÞÒ wrote:

> While messing with beast lately, I've been trying to add "save changes?"
> dialog when closing window. This turned out into quite an adventure of
> studying the beast source... I guess now I understand the meaning behind
> "Bedevilled" in the name :) Well, I finally implemented the
> functionality (and updated to filechooser). Patches attached, but
> there're still several points:
>
> * The project item_name (retreived with bse_item_get_name) is set to
> "Untitled.bse" on startup, but I think the directory path is stored in
> it later as well. I did not find a clear way to tell whenever a file has
> been saved to disk for the first time (for Save/Not-Save-As operation),
> so I added a boolean "first_time_save_flag" in bstapp.h/BstApp and a
> boolean "save_self_contained" to preserve self_contained ("fully include
> wave files") flag when saving the file later. first_time_save_flag is
> set to TRUE in bst_app_init, but to FALSE when opening project. I still
> don't know how to check if waves were included with the newly opened
> project...

this needs support in Bseproject first. the absolute filename has
to be stored there, and its undo recorder needs to be extended to report
whether a project has changed yet. that's basically the reason why beast
doesn't provide porper Save... and save-on-close semantics yet.

> * 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'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.

> 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.

> * 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.

> * When quitting with more than one unsaved file, a new dialog should
> popup asking which unsaved files to save (like the one in gedit).
> Generally polish the quit procedure.

the gedit behaviour is quite nice, but for the sake of simplicity,
i'd be fine with the gimp behaviour first, which simply asks to confirm
quitting in the presence of unsaved files.

> * Need to generate error strings from bse errors.

there is a function for that already, do man bse-procs.

> +    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 ();


> * 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"?


Please produce diffs with diff -up, that improves readability a lot.

> I also wonder what's the reason behind so much gxk/bst extra stuff? Why
> not use pure gtk where available/appropriate?

i am using gtk "where appropriate". there're lots of reasons for
gxk/bst things though:
- gtk lacks lots of convenience functions (gxkutils.h)
- gtk lacks a bunch of important functionality (lots of other gxk stuff)
- there're lots of bugs in gtk, some of which are bad enough, so that
  beast has to add extra code to work around them.
- beast needs special code for large and fast scrollable widgets
- beast supports skinning for it's large editing widgets
- gtk doesn't provide certain domain specific widgets required by beast (the
  reason for most of the Bst* widgets)
- there's special code to implement GUI auto-generation (gxkparam*,
  bstutils*, bstparam*, ...)
- writing GUIs with gtk in C is tedious to say the least. gxk introduces a
  new (experimental) approach, it allowes to write GUIs in xml. at this point,
  most non-generated beast dialogs are defined in
  beast-gtk/dialogs/radgets-beast.xml, which greatly reduces prototyping time
  and increases flexibility with GUI layouts.
- and then there's the rack editor, which is on its way to become a GUI
  editor in its own respect

occasionally, i collect stabelized and appropriate code and fold things back
into gtk or glib/gobject.

(beast traditionally has been one of the testbeds to develop experimental
gtk/glib stuff, e.g. the gobject system with interfaces was written for
bse before it got extended and moved to glib. another example is the
BstKennel which grouped widget sizes and later got recoded and moved into
gtk as GtkSizeGroup).

> --Artem
>

---
ciaoTJ