GNOME Bugzilla – Bug 328831
Dialog helper functions
Last modified: 2018-05-22 12:07:21 UTC
add some functions helping to automate common tasks, such as: showing an error message showing an information message ask for some textual information ask for answering a simple question with yes or no ask for a file name to open ask for a file name to save ask for a directory to open
Created attachment 58206 [details] Compilable code that provides the suggested functionality
So, this contains the following functions: > /// Updates the gui, i.e., any unattended GUI message is executed > void update_gui(); This is a possibility. If so, we should add it to GTK+. > void show_error_message(Gtk::Window &w, const string &msg); > void show_info_message(Gtk::Window &w, const string &msg); These should have secondary text. > void show_error_message(const string &msg); And this should have the Gtk::Window &w parameter. I'd prefer to have an optional argument to specify the message type. For instance: static MessageDialog::run_ok_dialog(const Glib::ustring& title, const Glib::ustring& message, Gtk::Window& parent, Gtk::MessageType message_type = Gtk::MESSAGE_INFO); > bool ask_YesNo(const string &, const string &, const string &); Yes/No dialogs are bad, and should not be encouraged: http://developer.gnome.org/projects/gup/hig/2.0/windows-alert.html#alert-button-order > string ask_filename_open(const string &title, const string & dirInit); > string ask_filename_save(const string &title, const string & dirInit); > string ask_directory_open(const string &title, const string & dirInit); These seem like candidates too. All these functions should use Glib::ustring for displayed text, and std::string for filenames.
Also, the implementation of these functions is appalling. They should use Gtk::MessageDialog.
> > void show_error_message(Gtk::Window &w, const string &msg); > > void show_info_message(Gtk::Window &w, const string &msg); > > These should have secondary text. Does this mean that I should add the secondary text to them ? > > void show_error_message(const string &msg); > And this should have the Gtk::Window &w parameter. Actually, show_error_message() and show_info_message() have overloaded versions that do not require the Window parameter. I do agree that creating the dialog without a parent shouldn't be supported, but sometimes can be of some use. I'm thinking that both versions can be melted in only one. If window is NULL, then the dialog can be displayed without parent. > I'd prefer to have an optional argument to specify the message type. For > instance: > > static MessageDialog::run_ok_dialog(const Glib::ustring& title, const > Glib::ustring& message, Gtk::Window& parent, Gtk::MessageType message_type = > Gtk::MESSAGE_INFO); That's possible. > > bool ask_YesNo(const string &, const string &, const string &); > > Yes/No dialogs are bad, and should not be encouraged: You can discard it. > > string ask_filename_open(const string &title, const string & dirInit); > > string ask_filename_save(const string &title, const string & dirInit); > > string ask_directory_open(const string &title, const string & dirInit); > > These seem like candidates too. > > All these functions should use Glib::ustring for displayed text, and > std::string for filenames. Absolutely. Anyway, tell me what to do: do you want me to modify these functions or should I just wait ?
(In reply to comment #3) > Also, the implementation of these functions is appalling. They should use > Gtk::MessageDialog. I suppose you refer to ask_YesNo() and ask_info(). They were created using glade, and I simply don't know whether they can be written using MessageDialog and how ... as I warned you, I am a newbie in gtkmm, as I warned you. The remaining functions shouls be okay, they use gtkmm "appropriately". Anyway, again, tell me what to do: do you expect me to write the changes and send them back here or what ?
Created attachment 58210 [details] Modification of the pevious code to address most of the comments from Murray Modification of the pevious code to address most of the comments from Murray - mixes the message functions in only one - removed the ask_YesNo() function - Glib::ustring used where necessary
I believe that the GTK+ developers think that we shouldn't encourage the use of gtk_dialog_run(), but I need to clarify that. I use it all the time myself.
I'm not convinced that any of this functionality is complicated enough to justify adding convenience functions for them within a general-purpose toolkit like gtkmm. Within an application, I think wrappers like this are often useful, but I don't really think we need to add them to gtkmm. In any case, I think some of these things could be more cleanly implemented as specializations of the class rather than standalone wrapper functions.
(In reply to comment #8) > I'm not convinced that any of this functionality is complicated enough to > justify adding convenience functions for them within a general-purpose toolkit > like gtkmm. Within an application, I think wrappers like this are often > useful, but I don't really think we need to add them to gtkmm. In any case, I > think some of these things could be more cleanly implemented as specializations > of the class rather than standalone wrapper functions. > Well, VCL (Borland Visual Library) has ShowMessage() and InputMessage(). C# in Windows.Forms has MessageBox.Show() as an static method. Convenience functions are there just because you want to make the life of your users [programmers] easier. Mmmm ... isn't the purpose of Gtkmm to make the life of Gtk+ users easier ? Maybe you tought: "these are functions with two or three lines of code". Well ... that's true. However, creating those lines made me browse _a_lot_ of documentation. Whatever you like. I simply was asked to present these functions here because they were supposed to be of general interest. As I said in the gtkmm list, they are so useful that everybody will end with their own implementation ... exactly as happened with C++ string class.
Created attachment 61289 [details] Utility functions and example of use This new archive includes: - Now implementation of some functions is not so appaling (using Gtk::MessageDialog) - Applied the Gtkmm coding style guidelines - An example using the utility functions was added - Added functions using a window as parent window and others being able to be standalone
(In reply to comment #10) > This new archive includes: > - Now implementation of some functions is not so appaling (using > Gtk::MessageDialog) > - Applied the Gtkmm coding style guidelines > - An example using the utility functions was added > - Added functions using a window as parent window and others being able to be > standalone > Isn't any interest about this ? -- Baltasar
> Isn't any interest about this ? As I said above: I believe that the GTK+ developers think that we shouldn't encourage the use of gtk_dialog_run(), but I need to clarify that. I use it all the time myself.
For the record, I vote against adding any API that encourages the user interface nightmare of a sequence of dialogs to click through. Generic message dialogs can already be created with only a handful of code lines anyway.
This seems like the only one that is actually generically useful. All the others would not be enough for any real-world use so we'd be encouraging less than perfect UI. For instance, a file chooser dialog should not be shown without specify a file filter, and a single-question, text-only question dialog is not generically useful. void show_ok_message( Gtk::Window &w, const Glib::ustring &msg, const Glib::ustring &sec_msg, Gtk::MessageType message_type = Gtk::MESSAGE_INFO); That could be suggested as a non-member function for GtkMessageDialog: http://library.gnome.org/devel/gtk/unstable/GtkMessageDialog.html
> void show_ok_message( Gtk::Window &w, const Glib::ustring &msg, const Glib::ustring &sec_msg, Gtk::MessageType message_type = Gtk::MESSAGE_INFO); > That could be suggested as a non-member function for GtkMessageDialog: Another possibility is to have it as a static function, so it would be invoked as: GtkMessageDialog::show_ok_message( "I've finished the backup", "The backup finished with status 0" );
The only way to make this work correctly with just one function call is a modal dialog. Also, I don't think it is enough if we can show that it can be used in a manner that is not broken. I think in order to justify the addition of convenience API, that situation should also be *frequent*.
(In reply to comment #16) > The only way to make this work correctly with just one function call is a modal > dialog. Well, it is a modal dialog. It wouldn't make sense in any other way. > Also, I don't think it is enough if we can show that it can be used in a manner > that is not broken. I think in order to justify the addition of convenience > API, that situation should also be *frequent*. I can only talk about my own experience. I created utility.cpp when I started to work with Gtk--, and I ported it to C# when I recently worked with Gtk#. For me, they are very useful, and they are definitely a must. About other languages and graphic toolkits, it appears in many incarnations. In C#, and specifically in Windows.Forms, a dialog such as the one shown by the utility function commented above, is created through a static function (MessageBox.Show). This function is actually overloaded for various uses, from the simplest (just a text message) to the most complex one (various buttons...). In Delphi/VCL, you have a convenient function (ShowMessage) with the same functionality. In Java/Swing, you do also have a static function (JOptionPane.showMessageDialog).
(In reply to comment #14) > void show_ok_message( > Gtk::Window &w, > const Glib::ustring &msg, > const Glib::ustring &sec_msg, > Gtk::MessageType message_type = Gtk::MESSAGE_INFO); > > That could be suggested as a non-member function for GtkMessageDialog: > http://library.gnome.org/devel/gtk/unstable/GtkMessageDialog.html So this is still a GTK+ issue as far as I'm concerned. Please file a GTK+ bug if you are interested.
Shall we close this as NOTABUG? At least not in gtkmm. Because I also agree that first, if designs can be agreed, it would be best to try to have this in GTK+ directly. While gtkmm is invaluable in allowing me to use C++, I also appreciate how it doesn't stray too far from GTK+ in the extra functionality it adds, so that when I code in GTK+ I don't end up wondering where all my favourite features went... (In reply to Murray Cumming from comment #7) > I believe that the GTK+ developers think that we shouldn't encourage the use > of gtk_dialog_run(), but I need to clarify that. I use it all the time > myself. Yup. It's been earmarked for deprecation for a long time, although this hasn't been formalised yet. See, for example: https://blogs.gnome.org/desrt/2012/02/26/sprout-and-the-bean/ There is a WIP branch of master where TingPing began to replace use of gtk_dialog_run() with the response/callback way of doing things. And I did the same in my main (gtkmm) project as a rainy-day bit of future-proofing. It's hard to deny that using responses/callbacks leads to more idiomatic code, which usually ends up being less intertwined and more easy to reason about/refactor. And that's before we get into the technical arguments against nested main loops, which desrt indicated in the comments. I'm sure there is more similar discussion elsewhere, though I can't recall any specific links at the moment.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtkmm/issues/1.