What was the decision on the live update of extensions? The original justification was that it would happen in a separate thread so you wouldn't notice, but it is *very* noticeable. At least on Windows with the snapshot builds. The worst part of it theres a DOS console that pops up every time the command gets rerun, and often that steals the focus away from the text field you're trying to type some number into. It's very annoying.
--bb
On 9/25/07, Bill Baxter <wbaxter@...400...> wrote:
What was the decision on the live update of extensions? The original justification was that it would happen in a separate thread so you wouldn't notice, but it is *very* noticeable. At least on Windows with the snapshot builds. The worst part of it theres a DOS console that pops up every time the command gets rerun, and often that steals the focus away from the text field you're trying to type some number into. It's very annoying.
Oh, and the real gem is that the DOS box steals the focus when you click on a spinbutton -- so the spinbutton thinks you're doing click and hold, resulting in a cascade of dos boxes popping up until you finally hit the parameter's min or max value.
--bb
On Tue, 2007-09-25 at 13:49 +0900, Bill Baxter wrote:
On 9/25/07, Bill Baxter <wbaxter@...400...> wrote: What was the decision on the live update of extensions? The original justification was that it would happen in a separate thread so you wouldn't notice, but it is *very* noticeable. At least on Windows with the snapshot builds. The worst part of it theres a DOS console that pops up every time the command gets rerun, and often that steals the focus away from the text field you're trying to type some number into. It's very annoying.
Oh, and the real gem is that the DOS box steals the focus when you click on a spinbutton -- so the spinbutton thinks you're doing click and hold, resulting in a cascade of dos boxes popping up until you finally hit the parameter's min or max value.
Well, we decided that "Live" would be adjustable by a checkbox, and it is. So, it shouldn't happen unless you select it.
As far as the command prompt window, I'm not sure. I asked, and it seems that no one knows why this happens on Windows, or if it was in previous builds of Inkscape. The thread kinda died.
--Ted
As far as the command prompt window, I'm not sure. I asked, and it seems that no one knows why this happens on Windows, or if it was in previous builds of Inkscape. The thread kinda died.
Ok... stop me if I'm wrong here, but I'm assuming effects work by calling python.exe with the name of script as an argument, and the parameters as plain text, right? If so, the command window appears because python is probably compiled as a CUI (command line user interface) app rather than a GUI app. When executables are compiled in windows, the linker specifies whether the app is CUI or GUI in the exe file header.
If you specify GUI, you get no command window, but also if you start the app from the command line none of your printfs will ever appear (which is presumably not what most python users do want). When the app is compiled as CUI you *always* get a command window, unles you already have the one you started the app in.
I don't really know, but I think it might be possible to force the command window not to show with some parameters in the win32 CreateProcess system call. I have felt though, for several reasons for quite some time that if at all possible, it would be much better to load python as a library, rather than as a process. First, because in windows processes take a long time to start, so the interactivity of extensions will always be very bad. Second, because of this window problem. Third, because it seems much more elegant to introduce the parameter values programmatically rather than as arguments on a command line. It would be quite a change, but I think the python-as-a-library approach would represent a substantial improvement.
Hope that helps Joel
----- Original Message ----- From: "Ted Gould" <ted@...11...> To: "Bill Baxter" <wbaxter@...400...> Cc: "Inkscape List Devel" inkscape-devel@lists.sourceforge.net Sent: Tuesday, September 25, 2007 7:15 AM Subject: SPAM-LOW: Re: [Inkscape-devel] Decision on live update of extensions
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--------------------------------------------------------------------------------
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2007-09-25 at 11:18 +0100, Joel Holdsworth wrote:
I have felt though, for several reasons for quite some time that if at all possible, it would be much better to load python as a library, rather than as a process. First, because in windows processes take a long time to start, so the interactivity of extensions will always be very bad. Second, because of this window problem. Third, because it seems much more elegant to introduce the parameter values programmatically rather than as arguments on a command line. It would be quite a change, but I think the python-as-a-library approach would represent a substantial improvement.
I agree. Time is the only restricting factor on this.
But, not to confuse the issue, there are two things that we can talk about on this subject. One, is the execution of our current effects in an embedded python instance. This would allow them to parse once, and make live preview much faster. Two, is adding the ability for python scripts when running in Inkscape to access more Inkscape internals.
I believe that one could, and should, be implemented before two. Also, that it would provide significant benefit to users.
--Ted
On 9/25/07, Joel Holdsworth <joel@...1709...> wrote:
As far as the command prompt window, I'm not sure. I asked, and it seems that no one knows why this happens on Windows, or if it was in previous builds of Inkscape. The thread kinda died.
Ok... stop me if I'm wrong here, but I'm assuming effects work by calling python.exe with the name of script as an argument, and the parameters as plain text, right? If so, the command window appears because python is probably compiled as a CUI (command line user interface) app rather than a GUI app. When executables are compiled in windows, the linker specifies whether the app is CUI or GUI in the exe file header.
Yep apparently it's using python.exe, which is the CUI version. Python comes with a second binary compiled as a GUI app called pythonw.exe that you can use when you don't want a console.
--bb
Ted Gould wrote:
As far as the command prompt window, I'm not sure. I asked, and it seems that no one knows why this happens on Windows, or if it was in previous builds of Inkscape. The thread kinda died.
If we look back in the archives I think we'll find that we decided to leave the DOS box there as an indication that something was happening, ie in place of a proper progress bar. Removing the DOS box is simply a matter of running the extensions with pythonw.exe rather than python.exe. Have we ever talked through what would need to take place to stop hardcoding the names of the interpreters?
Aaron
On 9/25/07, Aaron Spike <aaron@...749...> wrote:
Ted Gould wrote:
As far as the command prompt window, I'm not sure. I asked, and it seems that no one knows why this happens on Windows, or if it was in previous builds of Inkscape. The thread kinda died.
If we look back in the archives I think we'll find that we decided to leave the DOS box there as an indication that something was happening, ie in place of a proper progress bar.
In that case we definitely must get rid of the dos box, because now there's that "effect working..." window performing the same function.
On Tue, 2007-09-25 at 06:16 -0500, Aaron Spike wrote:
Ted Gould wrote:
As far as the command prompt window, I'm not sure. I asked, and it seems that no one knows why this happens on Windows, or if it was in previous builds of Inkscape. The thread kinda died.
If we look back in the archives I think we'll find that we decided to leave the DOS box there as an indication that something was happening, ie in place of a proper progress bar. Removing the DOS box is simply a matter of running the extensions with pythonw.exe rather than python.exe.
I'm all for switching to "pythonw.exe" then. I think that we have enough error handling to tell the user when nothing is happening. The only case we wouldn't catch is if the extension was to hang, which seems a little unlikely. But, I guess we could put in some sort of timeout.
Have we ever talked through what would need to take place to stop hardcoding the names of the interpreters?
I'm not sure what you mean here. Currently the defaults are coded in, but then you can override them with parameters. If you don't specify an interpreter the scripting implementation will try to execute them directly, so that would be the same as not specifying at all. Of course, you could just set the interpreter to "" in your preferences also.
--Ted
Ted Gould wrote:
On Tue, 2007-09-25 at 06:16 -0500, Aaron Spike wrote:
Have we ever talked through what would need to take place to stop hardcoding the names of the interpreters?
I'm not sure what you mean here. Currently the defaults are coded in, but then you can override them with parameters. If you don't specify an interpreter the scripting implementation will try to execute them directly, so that would be the same as not specifying at all. Of course, you could just set the interpreter to "" in your preferences also.
Oh, well that is fantastic. I haven't explored this area in a long while. And I very well could have misunderstood it when I explored it the first time. I vaguely remember Mental had to make a small change in Inkscape proper to allow ruby scripts to function. I could be wrong. Could you please add a little documentation on using nonstandard interpreters to the wiki? or point me to the place where these docs already exist?
Aaron
On Tue, 2007-09-25 at 11:48 -0500, Aaron Spike wrote:
Ted Gould wrote:
I'm not sure what you mean here. Currently the defaults are coded in, but then you can override them with parameters. If you don't specify an interpreter the scripting implementation will try to execute them directly, so that would be the same as not specifying at all. Of course, you could just set the interpreter to "" in your preferences also.
Oh, well that is fantastic. I haven't explored this area in a long while. And I very well could have misunderstood it when I explored it the first time. I vaguely remember Mental had to make a small change in Inkscape proper to allow ruby scripts to function. I could be wrong. Could you please add a little documentation on using nonstandard interpreters to the wiki? or point me to the place where these docs already exist?
Documentation, you know better than to ask for that :)
The table that Mental edited is this one:
http://inkscape.modevia.com/doxygen/html/namespaceInkscape_1_1Extension_1_1I...
It in the interpreter table which is what is used to handle the interpreter attribute. If the entry in the attribute matches one in the table then something is prefixed to the child data of the command element. Here is the code:
http://inkscape.modevia.com/doxygen/html/script_8cpp-source.php#l00113
The first thing that is checked is the preferences. Under the "extensions" object the specific interpreter is looked for. Otherwise the default in the table is used.
I hope that info helps.
--Ted
On 9/25/07, Ted Gould <ted@...11...> wrote:
On Tue, 2007-09-25 at 13:49 +0900, Bill Baxter wrote:
On 9/25/07, Bill Baxter <wbaxter@...400...> wrote: What was the decision on the live update of extensions? The original justification was that it would happen in a separate thread so you wouldn't notice, but it is *very* noticeable. At least on Windows with the snapshot builds. The worst part of it theres a DOS console that pops up every time the command gets rerun, and often that steals the focus away from the text field you're trying to type some number into. It's very annoying.
Oh, and the real gem is that the DOS box steals the focus when you click on a spinbutton -- so the spinbutton thinks you're doing click and hold, resulting in a cascade of dos boxes popping up until you finally hit the parameter's min or max value.
Well, we decided that "Live" would be adjustable by a checkbox, and it is. So, it shouldn't happen unless you select it.
Ok, that checkbox wasn't in the snapshot I was using. I just downloaded a Sept 25 snapshot, and it indeed has the "LivePreview" checkbox, but it seems not to do anything. The live update happens regardless of checked/unchecked status.
As far as the command prompt window, I'm not sure. I asked, and it
seems that no one knows why this happens on Windows, or if it was in previous builds of Inkscape. The thread kinda died.
I just tried renaming the "interpreter" to "pythonw" in one effect's .inx and that does indeed fix it.
--bb
On Wed, 2007-09-26 at 09:53 +0900, Bill Baxter wrote:
On 9/25/07, Ted Gould <ted@...11...> wrote: Well, we decided that "Live" would be adjustable by a checkbox, and it is. So, it shouldn't happen unless you select it.
Ok, that checkbox wasn't in the snapshot I was using. I just downloaded a Sept 25 snapshot, and it indeed has the "LivePreview" checkbox, but it seems not to do anything. The live update happens regardless of checked/unchecked status.
No offense, but I don't believe you. Seriously. There is no way that the logic of the program could be different on Windows vs. Linux vs. other people using Windows.
I don't know what other advice to give. Sorry.
--Ted
On 9/26/07, Ted Gould <ted@...11...> wrote:
On Wed, 2007-09-26 at 09:53 +0900, Bill Baxter wrote:
On 9/25/07, Ted Gould <ted@...11...> wrote: Well, we decided that "Live" would be adjustable by a checkbox, and it is. So, it shouldn't happen unless you select it.
Ok, that checkbox wasn't in the snapshot I was using. I just downloaded a Sept 25 snapshot, and it indeed has the "LivePreview" checkbox, but it seems not to do anything. The live update happens regardless of checked/unchecked status.
No offense, but I don't believe you. Seriously. There is no way that the logic of the program could be different on Windows vs. Linux vs. other people using Windows.
I don't know what other advice to give. Sorry.
Well believe what you will. Fortunately with the pythonw thing in place it's not so bad.
--bb
Bill, what windows version do you use? And what versions of glib etc?
I am trying to find out why things do not crash for you, but do crash for me.
For me: Windows XP SP2 glib: 2.12.12.0 gthread: 2.12.12.0 glibmm2.4-1: no version information. filesize = 9.314.151 bytes any other libs that are important?
Thanks! Johan
________________________________
From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Bill Baxter Sent: woensdag 26 september 2007 8:09 To: Ted Gould Cc: Inkscape List Devel Subject: Re: [Inkscape-devel] Decision on live update of extensions On 9/26/07, Ted Gould <ted@...11...> wrote:
On Wed, 2007-09-26 at 09:53 +0900, Bill Baxter wrote: > On 9/25/07, Ted Gould <ted@...11...> wrote: > Well, we decided that "Live" would be adjustable by a > checkbox, and it > is. So, it shouldn't happen unless you select it. > > Ok, that checkbox wasn't in the snapshot I was using. > I just downloaded a Sept 25 snapshot, and it indeed has the > "LivePreview" checkbox, but it seems not to do anything. The live > update happens regardless of checked/unchecked status. No offense, but I don't believe you. Seriously. There is no way that the logic of the program could be different on Windows vs. Linux vs. other people using Windows. I don't know what other advice to give. Sorry.
Well believe what you will. Fortunately with the pythonw thing in place it's not so bad.
--bb
On 9/26/07, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:
Bill, what windows version do you use? And what versions of glib etc?
I am trying to find out why things do not crash for you, but do crash for me.
For me: Windows XP SP2 glib: 2.12.12.0 gthread: 2.12.12.0 glibmm2.4-1: no version information. filesize = 9.314.151 bytes any other libs that are important?
Thanks! Johan
I haven't been building Inkscape myself since the last batch of dependencies got added. So I was just using a pre-built snapshot from here: http://inkscape.modevia.com/win32-snap/
The most recent one I installed was I think this: http://inkscape.modevia.com/win32-snap/inkscape-0709251000.7z
--bb
Ted Gould wrote:
On Wed, 2007-09-26 at 09:53 +0900, Bill Baxter wrote:
On 9/25/07, Ted Gould <ted@...11...> wrote: Well, we decided that "Live" would be adjustable by a checkbox, and it is. So, it shouldn't happen unless you select it.
Ok, that checkbox wasn't in the snapshot I was using. I just downloaded a Sept 25 snapshot, and it indeed has the "LivePreview" checkbox, but it seems not to do anything. The live update happens regardless of checked/unchecked status.
No offense, but I don't believe you. Seriously. There is no way that the logic of the program could be different on Windows vs. Linux vs. other people using Windows.
I don't know what other advice to give. Sorry.
Not so fast there buddy. I decided to get off my duff and make a new windows build for myself and I can confirm that this is a problem. I even deleted my preferences.xml file.
Aaron Spike
On Wed, 2007-09-26 at 07:01 -0500, Aaron Spike wrote:
Ted Gould wrote:
No offense, but I don't believe you. Seriously. There is no way that the logic of the program could be different on Windows vs. Linux vs. other people using Windows.
I don't know what other advice to give. Sorry.
Not so fast there buddy. I decided to get off my duff and make a new windows build for myself and I can confirm that this is a problem. I even deleted my preferences.xml file.
Okay, can I skeptical then? ;)
Seriously though, this is program logic, not anything that should be related to platforms.
Could you put a printf in ExecutionEnv::run in the two cases for the "if(_humanWait)" statement. One that prints if we're waiting on the human and one if we're waiting on the computer. If live effect is not enabled we should always be waiting on the human (they're slow).
--Ted
On 9/26/07, Aaron Spike <aaron@...749...> wrote:
Ted Gould wrote:
On Wed, 2007-09-26 at 09:53 +0900, Bill Baxter wrote:
On 9/25/07, Ted Gould <ted@...11...> wrote: Well, we decided that "Live" would be adjustable by a checkbox, and it is. So, it shouldn't happen unless you select it.
Ok, that checkbox wasn't in the snapshot I was using. I just downloaded a Sept 25 snapshot, and it indeed has the "LivePreview" checkbox, but it seems not to do anything. The live update happens regardless of checked/unchecked status.
No offense, but I don't believe you. Seriously. There is no way that the logic of the program could be different on Windows vs. Linux vs. other people using Windows.
I don't know what other advice to give. Sorry.
Not so fast there buddy. I decided to get off my duff and make a new windows build for myself and I can confirm that this is a problem. I even deleted my preferences.xml file.
Aaron Spike
I can third this, that check box doesnt do jack...
participants (7)
-
unknown＠example.com -
Aaron Spike -
Bill Baxter -
bulia byak -
Joel Holdsworth -
john cliff -
Ted Gould