Could someone puh-lease help me. I'm translating the python extensions to use lxml and the effects error dialog is really driving me nuts. It is modal and it doesnt' stay ontop of the inkscape window. This makes it the most annoying dialog ever. This is a Win32 problem. I run and effect that generates an error. I switch to a text editor to fix the error. I click back on inkscape and the error windows is below inkscape so I have to minimize all the other windows and then move inscape to the left or two the right to read or close the dialog. To make matters worse the dialog is always placed in the middle of the inkscape window, so I have to move inkscape every time. I tried to hack the dialogs ontop hack for this dialog and failed.
Aaron Spike
On Sun, 2007-06-17 at 22:20 -0500, Aaron Spike wrote:
Could someone puh-lease help me. I'm translating the python extensions to use lxml and the effects error dialog is really driving me nuts. It is modal and it doesnt' stay ontop of the inkscape window. This makes it the most annoying dialog ever. This is a Win32 problem. I run and effect that generates an error. I switch to a text editor to fix the error. I click back on inkscape and the error windows is below inkscape so I have to minimize all the other windows and then move inscape to the left or two the right to read or close the dialog. To make matters worse the dialog is always placed in the middle of the inkscape window, so I have to move inkscape every time. I tried to hack the dialogs ontop hack for this dialog and failed.
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?
--Ted
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. ;-)
Aaron Spike
Aaron 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.
I think you also have to hook up some functions for when the desktop is minimized etc: dialogs/find.cpp lines 672 and on ui/dialog/dialog.cpp lines 179 and on
I vote for gtkmm'ing the dialog; though I won't volunteer for doing it.
Cheers, Johan
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
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
Aaron Spike wrote:
Bob Jamison wrote:
This is a good reason to move forward with using an embedded Python interpreter as an alternative to shelling out.
How?
Aaron
Like the Scripts dialog, we make a GUI that can capture the stdout and stderr of the interpreter. (Already done). All we need to do is catch the FALSE and show the error in a dialog.
bob
On Thu, 2007-06-21 at 02:39 -0500, Bob Jamison wrote:
Aaron Spike wrote:
Bob Jamison wrote:
This is a good reason to move forward with using an embedded Python interpreter as an alternative to shelling out.
How?
Like the Scripts dialog, we make a GUI that can capture the stdout and stderr of the interpreter. (Already done). All we need to do is catch the FALSE and show the error in a dialog.
That's exactly what we're doing now. Well, we're always showing STDERR, but it's basically the same.
--Ted
participants (4)
-
unknown＠example.com -
Aaron Spike -
Bob Jamison -
Ted Gould