This is a good reason to move forward with using an embedded Python interpreter as an alternative to shelling out.
bob
Ted Gould wrote:
On Wed, 2007-06-20 at 06:24 -0500, Aaron Spike wrote:
Ted Gould wrote:
It is set to modal in the constructor. Should we be calling sp_transientize() on this dialog? Or, are you saying that's not working either?
Correct. On windows this does not work. Could we make it an actual gtkmmified inkscape dialog like the other dialogs? Or perhaps we could reuse the messages dialog that Bob uses for debugging on windows. Remove the modal limitation, have it append errors, and add a clear button? Seems pretty drastic, I know. But what we have now isn't working. I've had to totally change my programming practices to write code without errors. ;-)
Well, it is already GTKmm....
void Script::checkStderr (const Glib::ustring &data, Gtk::MessageType type, const Glib::ustring &message) { Gtk::MessageDialog warning(message, false, type, Gtk::BUTTONS_OK, true); warning.set_resizable(true); GtkWidget *dlg = GTK_WIDGET(warning.gobj()); sp_transientize(dlg);
I think the real issue with making it inherit from the other classes is that they're different types of dialogs. The error dialog is more of a warning, it's modal, you have to go through it. The standard Inkscape dialogs are designed to be more pallets, and they're managed by the dialog manager.
I vote you fix windows ;) Perhaps removing the "sp_transientize" would make things better?
--Ted