Re: Simple Yes/No dialog

["Freddie Unpenstein" <fredderic excite com>]

> if you want to make non-blocking dialogs, you have to take care
> i.e. that:
> - a lot of non-blocking-dialogs may be opened, and stay open.

gtk_widget_present() comes in handy there...  I *ALWAYS* do that with Preferences dialogues...  Instead of 
disabling prefs menu options, or ignoring them while the prefs window is open, I use gtk_widget_present(), 
just in case the window has been minimised or something (not sure what else present() can save us from).

Also, always link the dialog back to the window/document/feature that raised it.  If something happens that 
we need the answer, then just raise it again.  Something else that comes in handy here, is to split the 
action around the dialog check.  If the dialog isn't open, then just call the second function to complete the 
action.  if the dialog is open, and it's appropriate to the situation, add data to the dialog (even via a 
weak-ref or something) to execute the action (if still appropriate) when the dialog gets closed (since 
dialogues generally have to be explicitly destroyed, the actions will be performed after the responce has 
been processed).


> - either a dialog blocks some functionality, or there may be
> several identical dialogs, doing/asking the same. (in the 2nd case:
> what happens with i.e. 2 identical save-dialogs ? or: what happens
> to the 1st save-dialog when a 2nd was used to save the file)

Again, gtk_widget_present()...  For most such cases I create a global pointer for the dialog (initialised to 
null), and use a specific function to present the dialog.  In the function, I check whether the global 
pointer is null; if not, just gtk_widget_present() it.  If it is null, then create the dialog, and bind it to 
the global with a weak pointer (the pointer will be automatically NULL'd when the dialog closes).

With preferences dialogs I usually go one step further, and hide them instead of closing at all.  But also 
when I hide them, I'll set a timer to kill the window completely after some fairly long period; of course, 
it's a good idea to kill the timer if the window closes for some other reason, and kill the timer if the 
function is called to re-present the dialog.  It helps in this case to stash the timer id in a user data of 
the dialog.


> - these non-blocking-dialogs may hide behind i.e. the
> main-program-window. and if the non-blocking-dialogs "blocks" some
> action, you may drive the user crazy :(  (example: non-blocking
> save-dialog. it blocks the save-button, so that there's only 1
> save-dialog for this file. now, this save-dialog hides behind the
> main-window, and the users tries to save the file...)

gtk_widget_present().  (Or is it gtk_window_present()...  Nawww....  heh)  How many times do I need to say 
it?  But also put checks in for strange things...  Like the document it refers to being closed by some other 
means that neglected to check whether it needed to be saved or not.  Or, in the case of a "Save as...", and 
then someone comes along and just closes it, or chooses "Save".  I personally consider "Save as ..." to be 
independant of "Save".  So you can save it as many times as you want, with a "Save as ..." dialog sitting 
there waiting to be completed.  And using the function-to-present-dialog method, bringing up the "Save as 
..." dialog, and then picking "Save" on an unnamed document, you just allow the "Save as ..." function to 
re-present the dialog.

Likewise I've always felt that "Close" dialogs shouldn't hastle the user if the file's unmodified, but should 
otherwise present the options; "Save" (only if the file is named), "Save as ...", "Discard changes", and 
"Don't quit".  If these are the exact same functions used elsewhere like in the menu's, and the "Save as ..." 
dialog knows how to close itself when the document dissapears, then everything will work pretty well 
seamlessly.  (It's also helpful if the close dialog knows how to close itself if the document gets saved by 
another means)  This can be handled by a function called at the end of the function responsible for 
ultimately saving the file to whatever name is chosen, by providing the document with a "saved" hook (which 
shouldn't be tied into by the "Save as ..." dialog, btw).  The close dialog ties into that hook, such that 
when it's invoked, the dialog gets destroyed (and yet again, destruction of the dialog should remove the hook 
- this can be set up by the 
function responsible for (re-)presenting the close dialog).

The trick is to use what's already available.  It's all too easy to forget what GTK can already do, and end 
up complicating matters by re-inventing things.  Let things do what they're supposed to do.  When you click a 
dialog button, it should be responsible for performing its task, and concluding (closing) the dialog.  Let 
the closure of the dialog unravel any hooks, timers, etc. bound to it.  If a file closes, let its distruction 
destroy anything dealing with saving it (if it's a GObject itself, that can easily be acomplished by a weak 
reference).

I detest blocking dialogs...  And "always on top" splash screens; they're not too bad if you can just click 
on them to make them go away, except when they dissapear just as you click, and you end up clicking something 
that was beneath them!  ;)


Fredderic

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!