Re: File dialog improvements

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.

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

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

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

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"

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

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

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

7) I remove the docs subdir from toplevel Makefile.

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

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

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