Re: File dialog improvements

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

> On mar, 2004-09-28 at 02:12 +0200, Tim Janik wrote:
> ...
> > > 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?
> >
> Well, when you call gtk_dialog_run, the code flow(?) stops at this point
> until the user either clicks on one of the buttons or closes the dialog.
> e.g.

no. gtk_dialog_run() simply calls a main loop recursively until it received
specific events (say a button click) at which point it's recursive main
loop stops and the function returns.

> gtk_dialog_run (GTK_DIALOG (dialog)); // main_loop escaped somehow...
> gtk_widget_destroy (dialog); // here the user already clicked something
> in the dialog, we need to remove it (or parent) from the screen now

right, the same happens with bst_choice_modal() though:

/* immediately pops up a menu */
              choice = bst_choice_menu_createv ("<BEAST-SNetRouter>/ModulePopup",
                                                BST_CHOICE_TITLE (source_name),
                                                BST_CHOICE (2, _("Properties"), PROPERTIES),
                                                BST_CHOICE (6, _("Reset Properties"), PROPERTIES_RESET),
                                                BST_CHOICE_S (3, _("Delete Inputs"), NO_ILINK, has_inputs),
                                                BST_CHOICE_S (4, _("Delete Outputs"), NO_OLINK, bse_source_has_outputs (csource->source)),
                                                BST_CHOICE (5, _("Show Info"), INFO),
                                                BST_CHOICE_S (1, _("Delete"), DELETE, csource->source != self->snet),
/* waits until a menu item was selected */
              i = bst_choice_modal (choice, event->button.button, event->button.time);
/* here, the menu is popped down, probably destroyed */
              switch (i)

> > > > > * 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().
> >
> I recall *_set_data allow arbitrary data to be stored, no?

yes, bse_proxy_set_data() works like g_object_set_data().

> > > 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.
> >
> I'm currently having problems with building recent CVS:
> 1) I have to change automake/aclocal to automake-1.4/aclocal-1.4
> explicitly in otherwise autogen gets borked (it looks like
> they have 5 automakes (1.4 to 1.8) in gentoo + autoconfs 2.13 and 2.59).

beast's automatically checks for "automake1.4" and "automake-1.4".
could you tell me why exactly (attached) fails on your system?

> 2) I have to comment out enable-devel-rules in because they
> immediately require texiheque(?), i don't have this here.

the download area on the website describes the details of getting
it from the freedesktop CVS.

> 3) When calling make in bse/ dir I get errors like bse-genapi.h not
> found. So I have to do smth like "make stamp-bsegenapi"

i'd have to know the exact errors you're getting there. when
building with srcdir==builddir from CVS, the autogenerated files
in the bse/ directory are properly generated here.

> 4) "make stamp-bsegenapi" requires semihand-editing of bse/Makefile. I
> have to change all occurrences of "" to "./"... i
> beleive it could be $(SRCDIR)/

again, are you building from CVS with srcdir!=builddir? that is not
supported for a lot of reasons. it works correctly with the beast tarballs
though. i'll add a note about this to the "bleeding edge" section on CVS.

> 5) also have to change all occurrences of "" to
> "./" (of course the last 2 steps only in the indented(command)
> areas of Makefile).

same issue.

> 6) in beast-gtk dir, make fails to find bst-debug-keys.defs(?), I have
> to copy the file from the last tarball

you lack the devel build rules to create this file which need a tool from

> 7) I remove the docs subdir from toplevel Makefile.

texitheque again.

> Regarding the docs, why use texinfo, not docbook? I could convert them,
> if it seems ok to switch.

i really don't like docbook and like the texinfo syntax.
texinfo is GNU standard and comparatively easy to use and learn.

> > > "<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.
> >
> I think it's in the hig. You put the question in big font, and the 1-2
> lines-explanation below in normal font (like most dialogs in gnome).

again, how does that relate to all other dialogs?


Description: Bourne shell script

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]