Re: File dialog improvements

[Артём Попов <tfwo mail ru>]

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.

> 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 :(

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

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

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

All right, I'll rewrite this one.

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

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 :)

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

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

Understood. My mistake, I thought beast has lots of code duplication. --
Artem