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_SEPERATOR,
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_SEPERATOR,
BST_CHOICE_S (1, _("Delete"), DELETE, csource->source != self->snet),
BST_CHOICE_END);
/* 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 autogen.sh 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 autogen.sh automatically checks for "automake1.4" and "automake-1.4".
could you tell me why exactly autotest.sh (attached) fails on your system?
> 2) I have to comment out enable-devel-rules in autogen.sh 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 "mktypes.pl" to "./mktypes.pl"... i
> beleive it could be $(SRCDIR)/mktypes.pl
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 "mkcproc.pl" to
> "./mkcproc.pl" (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
texitheque.
> 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?
---
ciaoTJ
Attachment:
autotest.sh
Description: Bourne shell script