Hey all,
So I've finally got my work on switching the scripting extensions over to being a call with parameters instead of a parsed string on the command line. At the same time I've made them asynchronous, which has some nice side effects. Basically, this all involved reworking large portions of the scripting code -- which brings the possibility of breaking things. Two areas in specific that I'm worried about:
-- win32. Some of the functions I've used had notes on what does and doesn't work on win32, but the documentation was sparse, and I'm concerned it was incomplete.
-- internationalization. I know we've had problems in the past with this code and different locales of filesystem and UI. I believe I kept all that code in place -- but history means that those with the complex setups should be extra observant when noticing how their SVN builds run.
So other than those concerns, enjoy everyone. I hope this will add a lot of usability to the scripts, especially some discoverability to the parameters.
Have fun, Ted
On 6/27/07, Ted Gould <ted@...11...> wrote:
command line. At the same time I've made them asynchronous, which has some nice side effects.
And the most visible "side effect" is this: Effects are now live! You don't have to press OK to see the result. You change parameters in the window and the effect reruns in the background.
Now, while this is fun and often useful, it MUST be optional. Some effects take a long time to run and this will easily become an annoyance. I suggest that you add to every effect dialog a checkbox at the bottom, "Live preview," off by default, and make it remember its status across invocations.
Also, there must be some indication that the effect is now working - either in the editing window statusbar or in the effect window. It's very confusing to not be able to tell whether what I see has the effect already applied or not.
And, as always, please update http://wiki.inkscape.org/wiki/index.php/ReleaseNotes046 promptly and detailedly - thanks! (This is a requirement for anyone who adds any notable features or bugfixes to the codebase.)
On Wed, 2007-06-27 at 12:28 -0300, bulia byak wrote:
On 6/27/07, Ted Gould <ted@...11...> wrote:
command line. At the same time I've made them asynchronous, which has some nice side effects.
And the most visible "side effect" is this: Effects are now live! You don't have to press OK to see the result. You change parameters in the window and the effect reruns in the background.
Yes. It's kinda fun really :)
Now, while this is fun and often useful, it MUST be optional. Some effects take a long time to run and this will easily become an annoyance. I suggest that you add to every effect dialog a checkbox at the bottom, "Live preview," off by default, and make it remember its status across invocations.
I guess my question is, why? I considered this for a while, and the reality is that considering it doesn't restart when you hit OK, it will just make the effect appear faster. I can't come up with a use case for wanting it off. Even with slow machines it will just end up using "extra" CPU time while the user is looking at the dialog.
Also, there must be some indication that the effect is now working - either in the editing window statusbar or in the effect window. It's very confusing to not be able to tell whether what I see has the effect already applied or not.
Yes, I agree. It's just not done yet. I didn't want to get off the branch too much and I wanted to ensure the fundamentals of the async stuff worked first.
And, as always, please update http://wiki.inkscape.org/wiki/index.php/ReleaseNotes046 promptly and detailedly - thanks! (This is a requirement for anyone who adds any notable features or bugfixes to the codebase.)
Yes, I will.
--Ted
On 6/27/07, bulia byak wrote:
And the most visible "side effect" is this: Effects are now live! You don't have to press OK to see the result. You change parameters in the window and the effect reruns in the background.
There is another "side effect". Now that all effects are live, one would want to be able to zoom out or pan or both, but effects dialogs are modal and don't allow that.
Alexandre
On Wed, 2007-07-11 at 03:40 +0400, Alexandre Prokoudine wrote:
On 6/27/07, bulia byak wrote:
And the most visible "side effect" is this: Effects are now live! You don't have to press OK to see the result. You change parameters in the window and the effect reruns in the background.
There is another "side effect". Now that all effects are live, one would want to be able to zoom out or pan or both, but effects dialogs are modal and don't allow that.
Effects dialogs have always been modal. Actually, very little changed in the dialog itself.
--Ted
On 7/11/07, Ted Gould wrote:
There is another "side effect". Now that all effects are live, one would want to be able to zoom out or pan or both, but effects dialogs are modal and don't allow that.
Effects dialogs have always been modal. Actually, very little changed in the dialog itself.
Of course they have and this is not the point of my message :)
Before, when extension were... errr... not live :), nobody cared, if the dialog was modal or not. Now people will.
Alexandre
On 7/11/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
Before, when extension were... errr... not live :), nobody cared, if the dialog was modal or not. Now people will.
I don't think we can make them unmodal. If you change anything in the document while the effect is running, your changes will be lost when it finishes - and this is a much worse bug.
On 6/27/07, Ted Gould <ted@...11...> wrote:
So I've finally got my work on switching the scripting extensions over to being a call with parameters instead of a parsed string on the command line.
Perhaps caused by this, now (at least) enum parameters get extra quotes around them. This breaks (at least) the Barcode extension which in share/extensions/Barcode/__init__.py tries to compare "ean13" with quotes with ean13 without quotes and fails.
bulia byak wrote:
On 6/27/07, Ted Gould <ted@...11...> wrote:
So I've finally got my work on switching the scripting extensions over to being a call with parameters instead of a parsed string on the command line.
Perhaps caused by this, now (at least) enum parameters get extra quotes around them. This breaks (at least) the Barcode extension which in share/extensions/Barcode/__init__.py tries to compare "ean13" with quotes with ean13 without quotes and fails.
Barcode is still otherwise broken until I get a chance to fix it.
Aaron
On Wed, 2007-06-27 at 13:12 -0300, bulia byak wrote:
On 6/27/07, Ted Gould <ted@...11...> wrote:
So I've finally got my work on switching the scripting extensions over to being a call with parameters instead of a parsed string on the command line.
Perhaps caused by this, now (at least) enum parameters get extra quotes around them. This breaks (at least) the Barcode extension which in share/extensions/Barcode/__init__.py tries to compare "ean13" with quotes with ean13 without quotes and fails.
Ah, yes. The previous work around. I'll fix that.
--Ted
Ted Gould wrote:
Ah, yes. The previous work around. I'll fix that.
Help! On win32 I get:
Make error line 176: problem compiling: src/extension/implementation/plugin.cpp: In member function 'virtual Gtk::Widget* Inkscape::Extension::Implementation::P lugin::prefs_effect(Inkscape::Extension::Effect*, Inkscape::UI::View::View*)': src/extension/implementation/plugin.cpp:229: error: no matching function for cal l to 'Inkscape::Extension::Implementation::Plugin::prefs_effect(Inkscape::Extens ion::Effect*&, Inkscape::UI::View::View*&)' src/extension/implementation/implementation.h:66: note: candidates are: virtual Gtk::Widget* Inkscape::Extension::Implementation::Implementation::prefs_effect(I nkscape::Extension::Effect*, Inkscape::UI::View::View*, sigc::signal<void, sigc: :nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil>*)
Aaron
On Thu, 2007-06-28 at 06:32 -0500, Aaron Spike wrote:
Ted Gould wrote:
Ah, yes. The previous work around. I'll fix that.
Help! On win32 I get:
Well, plugin.cpp isn't maintained and isn't built on Linux. I'm for deleting it from the repository for now (mostly because it doesn't seem feasible on win32 -- which is rather ironic).
Is there a way to use the autotools build for win32? It's mighty frustrating that the builds are so different. We've run into that twice in the last couple days with the style-test and now this. At least we need to be reading the same file lists, though the same build options and such would be better.
--Ted
On Thu, 28 Jun 2007 08:57:47 -0700, Ted Gould <ted@...11...> wrote:
Well, plugin.cpp isn't maintained and isn't built on Linux. I'm for deleting it from the repository for now (mostly because it doesn't seem feasible on win32 -- which is rather ironic).
+1. The only good dead code is deleted dead code.
-mental
Ted Gould wrote:
On Thu, 2007-06-28 at 06:32 -0500, Aaron Spike wrote:
Ted Gould wrote:
Ah, yes. The previous work around. I'll fix that.
Help! On win32 I get:
Well, plugin.cpp isn't maintained and isn't built on Linux. I'm for deleting it from the repository for now (mostly because it doesn't seem feasible on win32 -- which is rather ironic).
Or we could add it to the exclude list, which we have done for lots of files.
Is there a way to use the autotools build for win32? It's mighty frustrating that the builds are so different. We've run into that twice in the last couple days with the style-test and now this. At least we need to be reading the same file lists, though the same build options and such would be better.
Conversely, we could drop autotools. :-)
bob
On Thu, 2007-06-28 at 11:09 -0500, Bob Jamison wrote:
Ted Gould wrote:
Is there a way to use the autotools build for win32? It's mighty frustrating that the builds are so different. We've run into that twice in the last couple days with the style-test and now this. At least we need to be reading the same file lists, though the same build options and such would be better.
Conversely, we could drop autotools. :-)
Well, honestly, of everything that's gone through the list on this I haven't seen anything as complete. And, I'm not really interesting in the Inkscape project having it's own build tool. Not to restart this whole conversation, but besides it's being complex, I'm not that unhappy with autotools.
--Ted
On Thu, 28 Jun 2007 10:28:03 -0700, Ted Gould <ted@...11...> wrote:
Well, honestly, of everything that's gone through the list on this I haven't seen anything as complete. And, I'm not really interesting in the Inkscape project having it's own build tool. Not to restart this whole conversation, but besides it's being complex, I'm not that unhappy with autotools.
Complex is a little bit of an understatement...
The big elephant in the room is that we don't have any developers who really understand autotools.
-mental
On Thu, 2007-06-28 at 11:22 -0700, MenTaLguY wrote:
On Thu, 28 Jun 2007 10:28:03 -0700, Ted Gould <ted@...11...> wrote:
Well, honestly, of everything that's gone through the list on this I haven't seen anything as complete. And, I'm not really interesting in the Inkscape project having it's own build tool. Not to restart this whole conversation, but besides it's being complex, I'm not that unhappy with autotools.
Complex is a little bit of an understatement...
The big elephant in the room is that we don't have any developers who really understand autotools.
In my experience, the heard of elephants in the room is that I've never found anyone who claims to understand autotools ;)
But, I will say that autotools makes a lot of things like cross-compiling very easy when it does get set up. Setting it up seems to be the hardest part.
--Ted
On Thu, 2007-06-28 at 10:28 -0700, Ted Gould wrote:
On Thu, 2007-06-28 at 11:09 -0500, Bob Jamison wrote:
Ted Gould wrote:
Is there a way to use the autotools build for win32? It's mighty frustrating that the builds are so different. We've run into that twice in the last couple days with the style-test and now this. At least we need to be reading the same file lists, though the same build options and such would be better.
Conversely, we could drop autotools. :-)
Well, honestly, of everything that's gone through the list on this I haven't seen anything as complete. And, I'm not really interesting in the Inkscape project having it's own build tool. Not to restart this whole conversation, but besides it's being complex, I'm not that unhappy with autotools.
--Ted
Agree...don't fix it if it ain't broke...How is JS integration anyway?
Jon
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Ted Gould wrote:
On Thu, 2007-06-28 at 11:09 -0500, Bob Jamison wrote:
Ted Gould wrote:
Is there a way to use the autotools build for win32? It's mighty frustrating that the builds are so different. We've run into that twice in the last couple days with the style-test and now this. At least we need to be reading the same file lists, though the same build options and such would be better.
Conversely, we could drop autotools. :-)
Well, honestly, of everything that's gone through the list on this I haven't seen anything as complete. And, I'm not really interesting in the Inkscape project having it's own build tool. Not to restart this whole conversation, but besides it's being complex, I'm not that unhappy with autotools.
--Ted
Heh. Of course not. I'm just saying that one is as valid as another as the "master" file list. It would be nice if some projects could agree on dependency lists. It is sad to admit it, but VC's XML project format is not bad.
bob
On 6/29/07, Bob Jamison <rwjj@...127...> wrote:
Ted Gould wrote:
On Thu, 2007-06-28 at 11:09 -0500, Bob Jamison wrote:
Ted Gould wrote:
Is there a way to use the autotools build for win32? It's mighty frustrating that the builds are so different. We've run into that twice in the last couple days with the style-test and now this. At least we need to be reading the same file lists, though the same build options and such would be better.
Conversely, we could drop autotools. :-)
Well, honestly, of everything that's gone through the list on this I haven't seen anything as complete. And, I'm not really interesting in the Inkscape project having it's own build tool. Not to restart this whole conversation, but besides it's being complex, I'm not that unhappy with autotools.
--TedHeh. Of course not. I'm just saying that one is as valid as another as the "master" file list. It would be nice if some projects could agree on dependency lists. It is sad to admit it, but VC's XML project format is not bad.
[I have a feeling I've said all this before but here goes again anyway...]
I personally think using XML for describing builds is a bad idea, BUT if you want to do it that way, the Bakefile system does a pretty good job of it. The nice thing about bakefile is that it generates 100% native build solutions for a wide variety of compilers. It will generate autoconf stuff. It will generate Visual Studio projects. It will generate plain makefiles for a bunch of different compilers including MinGW. It's used by / developed by wxWidgets people. The idea is only core developers need to touch the bakefiles. Everyone else can just use the build files generated by it. The distinction makes a lot of sense for a library like wxWidgets. Not sure it makes so much sense for an app.
The other one that comes up a lot is CMake. It also generates more or less native solutions. I only have experience with the Visual Studio projects it generates. These aren't real visual studio projects though. They're like zombies that look like visual studio but have a lot of wierd stuff going on under the hood that is very unlike the way Visual Studio normally works. So I'm not so high on CMake from a user's perspective. The current buildtool.exe thing on Windows is MUCH less hassle than CMake.
SCons might also be a decent alternative if the Automake replacement stuff being worked on for Summer of Code works out.
--bb
Bob Jamison wrote:
Ted Gould wrote:
On Thu, 2007-06-28 at 06:32 -0500, Aaron Spike wrote:
Ted Gould wrote:
Ah, yes. The previous work around. I'll fix that.
Help! On win32 I get:
Well, plugin.cpp isn't maintained and isn't built on Linux. I'm for deleting it from the repository for now (mostly because it doesn't seem feasible on win32 -- which is rather ironic).
Or we could add it to the exclude list, which we have done for lots of files.
I've gone ahead and committed a build.xml that has this excluded. It compiles and runs, however, when I try to run any effects I get an error saying "python.exe - Unable to Locate Component" which continues "This application has failed to start because python25.dll was not found."
I have up-to-date libs and even found said python25.dll sitting in my inkscape directory. Anyway, figured I would bring it up.
-Josh
Ted,
on SVN, effects without UI don't work, such as those in the Color submenu. They just return immediately and do nothing.
I have some uncommitted style changes in my tree, which may affect this, but I doubt that. Can anyone please confirm?
bulia byak wrote:
Ted,
on SVN, effects without UI don't work, such as those in the Color submenu. They just return immediately and do nothing.
I have some uncommitted style changes in my tree, which may affect this, but I doubt that. Can anyone please confirm?
Confirmed that they don't work. Also, is L-system working for anyone?
-Josh
participants (9)
-
Aaron Spike -
Alexandre Prokoudine -
Bill Baxter -
Bob Jamison -
bulia byak -
Jon Phillips -
Joshua A. Andler -
MenTaLguY -
Ted Gould