As someone suggested, my problem of effects not working on Windows was indeed due to another Python installed in the PATH. After I removed that, it picked up Inkscape's own python and all worked fine.
Therefore, I suggest that we do three things:
1. Designate this as a mustfix bug for the release: Inkscape must always use its own python, not something in PATH. Certainly I'm not the only one with Python installed on Windows, so this issue is bound to happen to other people.
2. Enable extensions/effects by default and remove the prefs setting. I don't know of anything that prevents us from doing that.
3. Release a 0.44pre0.
Thoughts?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Wed, May 10, 2006 at 09:46:58PM -0400, bulia byak wrote:
As someone suggested, my problem of effects not working on Windows was indeed due to another Python installed in the PATH. After I removed that, it picked up Inkscape's own python and all worked fine.
Therefore, I suggest that we do three things:
- Designate this as a mustfix bug for the release: Inkscape must
always use its own python, not something in PATH. Certainly I'm not the only one with Python installed on Windows, so this issue is bound to happen to other people.
Sounds good. Who would be the owner for this? Do you have an idea of what other mustfix bugs there are?
- Enable extensions/effects by default and remove the prefs setting.
I don't know of anything that prevents us from doing that.
This probably should have been done earlier, to give additional time for testing, but you're right that now's the time to turn it on by default.
- Release a 0.44pre0.
Let's hold off on pre-releases until we've achieved feature freeze (planned for the 15th).
Bryce
On 5/10/06, Bryce Harrington <bryce@...961...> wrote:
Sounds good. Who would be the owner for this? Do you have an idea of what other mustfix bugs there are?
I think Ted is the most natural owner.
Other mustfix bugs include at least:
- the snapping freeze (I don't know if Carl fixed it but I think not)
- the freeze in the bitmap tracer
- mental's problem with tablet dragging
They're all in the tracker.
- Release a 0.44pre0.
Let's hold off on pre-releases until we've achieved feature freeze (planned for the 15th).
I think we have SO much new stuff to test that the earlier we start
On 5/11/06, bulia byak <buliabyak@...400...> wrote:
I think we have SO much new stuff to test that the earlier we start
the better :)
Maybe just wait for Scislac to commit the tutorial updates and then do a prerelease, even if some features are still not there.
bulia byak wrote:
On 5/11/06, bulia byak <buliabyak@...400...> wrote:
I think we have SO much new stuff to test that the earlier we start
the better :)
Maybe just wait for Scislac to commit the tutorial updates and then do a prerelease, even if some features are still not there.
The tutorial updates are coming shortly (probably before noon)... I'm finishing up re-generating the other languages. However, I am unable to generate the tracing tutorial because it throws errors on the png files, so those won't be in this initial commit. Additionally, I have to piece in the doc-docbook changes because I have a feeling that tortoisesvn will be a pain.
For note, my masks/clippaths/pattern tutorial won't be in till this weekend as it still has a ways to go.
-Josh
On Thu, May 11, 2006 at 11:29:16AM -0400, bulia byak wrote:
On 5/11/06, bulia byak <buliabyak@...400...> wrote:
I think we have SO much new stuff to test that the earlier we start
the better :)
Maybe just wait for Scislac to commit the tutorial updates and then do a prerelease, even if some features are still not there.
Okay, well my one concern is the amount of unfinished development work. But perhaps we could use this event to emphasize the feature freeze.
Since Ted is not going to be able to do the release packages, we will need a volunteer to take his role in producing them. Would someone be willing to take on this role?
Bryce
On Wed, 10 May 2006, bulia byak wrote:
- Designate this as a mustfix bug for the release: Inkscape must
always use its own python, not something in PATH. Certainly I'm not the only one with Python installed on Windows, so this issue is bound to happen to other people.
Is there ever a reason that you'd want to use the version in the PATH? It seems atleast for testing you might want to use a different version.
- Enable extensions/effects by default and remove the prefs setting.
I don't know of anything that prevents us from doing that.
I agree. I think we should make the "configurable menu" the whiteboard menu and make it compile in by default. Thoughts?
- Release a 0.44pre0.
While I have no problem building releases, I have issues with consistent net access right now -- so it would be hard for me to upload them. (hopefully the bcm43xx driver in 2.6.17 will solve this, Bryce can you go kick Linus and get him to release it?) This is why all of my checkins have been 'batches' and why I'm rarely in the chat room. While I enjoy the task, someone else should probably be the 'release builder' for this revision.
--Ted
On 5/11/06, ted@...11... <ted@...11...> wrote:
On Wed, 10 May 2006, bulia byak wrote:
- Designate this as a mustfix bug for the release: Inkscape must
always use its own python, not something in PATH. Certainly I'm not the only one with Python installed on Windows, so this issue is bound to happen to other people.
Is there ever a reason that you'd want to use the version in the PATH? It seems atleast for testing you might want to use a different version.
If you want to test how some changes affect it, just make those changes to Inkscape's python and test. Or make inkscape/share/python a symlink/batch file calling the "real python". Anyway, I don't think we need to add an option for that.
- Enable extensions/effects by default and remove the prefs setting.
I don't know of anything that prevents us from doing that.
I agree. I think we should make the "configurable menu" the whiteboard menu and make it compile in by default. Thoughts?
Last I heard, it even gets compiled in the Windows version. If it also works :) let's just enable it always.
In Linux binaries we provide, I think it should also be enabled, and the library it uses linked statically. Is this possible?
While I have no problem building releases, I have issues with consistent net access right now -- so it would be hard for me to upload them. (hopefully the bcm43xx driver in 2.6.17 will solve this, Bryce can you go kick Linus and get him to release it?) This is why all of my checkins have been 'batches' and why I'm rarely in the chat room. While I enjoy the task, someone else should probably be the 'release builder' for this revision.
So we need a tarball king :) Volunteers welcome!
On Thu, 11 May 2006, bulia byak wrote:
Is there ever a reason that you'd want to use the version in the PATH? It seems atleast for testing you might want to use a different version.
If you want to test how some changes affect it, just make those changes to Inkscape's python and test. Or make inkscape/share/python a symlink/batch file calling the "real python". Anyway, I don't think we need to add an option for that.
Okay, sounds good. Can someone tell me how we know the location of "our" python on windows?
- Enable extensions/effects by default and remove the prefs setting.
I don't know of anything that prevents us from doing that.
I agree. I think we should make the "configurable menu" the whiteboard menu and make it compile in by default. Thoughts?
Last I heard, it even gets compiled in the Windows version. If it also works :) let's just enable it always.
In Linux binaries we provide, I think it should also be enabled, and the library it uses linked statically. Is this possible?
I static linking is a really bad idea, especially for a library that is network facing. I understand that we have to do it on Windows, but Linux has good dependency management, and we should use it. I think loudmouth is reasonably well distributed.
--Ted
participants (4)
-
unknown＠example.com -
Bryce Harrington -
bulia byak -
Joshua A. Andler