Inkscape

Joel Holdsworth wrote:
>  We discussed
> this already on this list, and came to the conclusion that that feature
> is not necessary for the Windows users, because Windows users don't
> expect it, and adding extra features to the standard dialog undermines
> the very reason native dialogs were implemented in the first place: to
> improve consistency!
>
> So my suggestion would be this: Put windows shortcuts in your home
> folder. Wouldn't that do the job? - in a neat windowsy sort of way?
>
> What do you think?
> Joel
Thank you for the suggestion! Yes placing shortcuts in MyDocuments does 
help, and it makes sense to think about OS consistency.

> At this stage it doesn't really sound promising. Besides, as of 5 months
> ago, this old MS fanboy has finally given up faith is Microsoft, and
> moved over to Ubuntu - which I love. So in a sense it feels a bit odd
> adding features that encourage people on to Vista, because really I want
> MS to go away, and everybody to join me on Linux. I'm being silly - it
> doesn't really work that way - I'll add support for it if it becomes
> practical.
I used to have Ubuntu64 on this machine along with WinXP (on AMD64 3000) until the routine win C: reformat after which Ubuntu was inaccessible. I guess boot partitions got corrupted? When I tried to install Ubuntu again it crashed during installation. Any idea what I might do to get Ubuntu back?

Remember too, that we are mainly talking about one bug, the 
https://bugs.launchpad.net/inkscape/+bug/179988 ability to print , which
IMHO must be working for a Windows release. A lot of the other things like
native dialogues (which is close) or OCAL importing (mabe not so close) can
be reverted or turned off if they are causing problems, at least until the
0.46.1 release (which may even be Windows only). Even upside down text in
PDF export can be fudged by forcing text to path until that is fixed. But no
printing is pretty much life or death for most people.
-- 
View this message in context: http://www.nabble.com/0.46-release-debate-tp15773115p15773120.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Native dialogs will not be shipped with 0.46. I committed them only
after the 0.46 build was branched.

On Sat, 2008-03-01 at 03:05 -0800, rygle wrote:
> Remember too, that we are mainly talking about one bug, the 
> https://bugs.launchpad.net/inkscape/+bug/179988 ability to print , which
> IMHO must be working for a Windows release. A lot of the other things like
> native dialogues (which is close) or OCAL importing (mabe not so close) can
> be reverted or turned off if they are causing problems, at least until the
> 0.46.1 release (which may even be Windows only). Even upside down text in
> PDF export can be fudged by forcing text to path until that is fixed. But no
> printing is pretty much life or death for most people.

rygle wrote:
> Just my two cents worth on the release being held back by Windows;
> 
> I think that, regardless of your position on Windows as an operating system,
> or Windows users, that putting out a release that is crippled would be
> downright humiliating to the *whole* Inkscape project.

I'm a Windows user. I use Windows daily. I'm very thankful when the OSS
software that I use is supported on Windows. But there are plenty of OSS
applications that aren't supported on Windows. It just can't happen in 
the FOSS ecosystem without people. People who are willing and interested 
in volunteering time and effort to support their platform. I do not 
thing a Windows-less release is humiliating to the people in the 
Inkscape project who have worked hard this release cycle to add features 
and fix bugs and document and translate and triage and advertise. These 
people have done a great job and deserve commendation. A Windows-less 
release is only humiliating to the Windows using portion of the community.

> Let's ask, what is pushing us so hard to get the next release out? In a lot
> of these projects there is an impetus based on saving face, which is about
> bringing new features to fruition. IMHO, the saving face needs to be done by
> being a little patient, or at the very least not releasing 0.46 for Windows
> until it is pretty right.

Please explain how you have arrived at the supposition that the
motivation for this Inkscape release is about "saving face"? It is a
goal of our project to have timely releases. This is a good goal for
every OSS project. It helps projects to move forward and gauge progress.
And it helps us slow down and focus on identifying and resolving a large
number of issues with functionality and stability.

> Again, what is the aim? Is it purely to further the name of Inkscape, or is
> there at least some desire to further SVG as a viable option is a largely
> proprietary world? I have heard that said a number of times, and used as a
> reason to include or reject features. This project is meant to be about a
> good SVG editor, and the rest is a nice by-product. Again, a good reason to
> hold off just a little.

Please explain how you have arrived at the supposition that this release
could be purely to further the name of Inkscape.

> Let us also ask, if Linux users are so technically superior, aren't they
> already using the release candidate, which offers pretty much what the
> release will? Surely even the nightlies are very stable by now if all the
> bugs are ironed out. If so, in at least one sense who cares if there's a
> release if the RC is working and those who want the release are already
> using it!  Linux users are well and truly used to beta and release
> candidates, and in fact the pure only use the bleeding edge stuff and look
> down on those who don't. Or are we next going to start railing against
> Ubuntu users for their lack of technical expertise, and because they need a
> packaged version? Afterall, isn't Ubuntu trying to attract that Windows-like
> person?

I find this paragraph insultingly stereotypical. There are technical and
non-technical people in every demographic. Linux users very often prefer
to use their distro's package management system. When I use linux
(Ubuntu), this is my preference and I don't believe myself to be
particularly lacking in technical expertise.

> Lets please hold off just a little, at the very least on the Windows
> release. For many Linux users it makes no difference whether or not there's
> an official release, because the pre2 package is stable. For the Windows
> users, and the reputation of Inkscape, SVG, and even FOSS, it makes a huge
> difference.

I believe that the arguments you have made, because of their tone, do
more to distract from your argument rather than support it. The lack of
a Windows package for this release would sadden me greatly. But I cannot
demand that developers who don't have access to windows for
philosophical reasons, monetary reasons, or even simple preference
support the development for that platform. If no one will support
Inkscape on Windows, it cannot exist.

Aaron Spike

Thanks Aaron,

I agree with lots of your comments, but I think you have somewhat
misunderstood me. I too am very thankful for FOSS software, and the many
people behind it. I am merely pleading that we don't release a *Windows
version* that is crippled, particularly in the area of printing (see the bug
I mentioned).

All I am asking is that there be patience with the *windows* release,
because for those who aren't as technically astute, a release that can't
print is going to scare them off. Hence the comment about humiliating. And I
think not just Inkscape, but FOSS, and SVG too.


Aaron Spike wrote:
> 
> A Windows-less release is only humiliating to the Windows using portion of
> the community.
> 

Not what I was saying.  A windows-crippled release, which has been strongly
suggested in the area of printing, would scare a lot of people away. I just
gave out fifteen CDs with Inkscape 0.45.1 this week, and I didn't give out
the Dev version, because I knew it wasn't ready. I would not give out a
print crippled version of 0.46, because there's a lot of negative PR in that
sort of thing. That's what I meant about humiliation.



> Please explain how you have arrived at the supposition that the
> motivation for this Inkscape release is about "saving face"? It is a
> goal of our project to have timely releases. This is a good goal for
> every OSS project. It helps projects to move forward and gauge progress.
> And it helps us slow down and focus on identifying and resolving a large
> number of issues with functionality and stability.
> 

I agree and support moving forward. I guess I feel very discouraged that
members of the community have started to use windows people as the whipping
boy that is holding back the release. I would even describe it as railing
against them. Windows people are still people. Non-programmers are still
people. And when people are strongly suggesting that we should just drop
printing, after several other rants, it makes me really start to question
motives.



> I find this paragraph insultingly stereotypical. ...I believe that the
> arguments you have made, because of their tone, do more to distract from
> your argument rather than support it.
> 

Well, I feel like my tone is a lot gentler than several comments I've seen
lately from others, and felt I needed to ask for some patience. I don't
demand anything from any developers, and I am not asking anyone to spend
money or time, but I *ask* for some patience from some on the windows
version.

I probably didn't say clearly enough that I don't mind a late release on
Windows, just not a crippled release in such an important area as printing.
Hopefully that is now clear, and hopefully it would mean that no-one would
have to rant, me included. </flame>
-- 
View this message in context: http://www.nabble.com/0.46-release-debate-tp15773115p15777072.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Speaking of releases, I still really want to see tref working (or if 
not, then the release notes need to be updated).  I have been suddenly 
swamped with school work so my compile fun to find the commit that 
caused the issue has been temporarily halted.

So, my question is, what are we looking at for a release date at this 
moment, and does anyone want to help me at least narrow down the commit? 
:)  Right now I believe everything worked after Rev 15430, and doesn't 
work by 15362.  If you are willing to help me, please email off list and 
you will be forever my best friend!! I should be able to then look at 
the problem a lot more easily if I can narrow down the commit a bit more.

Gail

On Sat, Mar 1, 2008 at 7:05 AM, rygle <pittos@...> wrote:
>
>  Remember too, that we are mainly talking about one bug, the
>  https://bugs.launchpad.net/inkscape/+bug/179988 ability to print , which
>  IMHO must be working for a Windows release.

I agree. I think the discussion is mostly prompted by Bryce's comment
that if we don't right now have someone to work on this bug, we must
not let it stop the release. With this I disagree. This might be true
of other bugs but not this one. With such a serious regression, we
must indeed wait as long as necessary for someone to come up and fix
it.

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

How did you get inkscape to run under valgrind? When I tried it, it
seemed to go wrong because the GC is incompatible.

On Sat, 2008-03-01 at 01:14 -0800, Jon A. Cruz wrote:
> I just did a change to NRRect's default constructor.
> 
> Prior to this it was leaving all of its members uninitialized, and  
> valgrind found that some like this were being checked for 'empty'. So  
> random behavior could have been seen.
> 
> I also did a fix under display, but that was an array index going  
> below zero, but I think the loop would have exited anyway, so I don't  
> expect that change to really affect the program.
> 
> 
> I'm mainly concerned that some bugs might have been caused by 'new'  
> NRRect variables being seen as non-empty and now they'll show up as  
> empty.
> 
> 
> BTW, these were the first two things I found by getting to run under  
> Valgrind and seeing what was reported right off the bat. I'll  
> probably try to actually explore the app a little more under  
> valgrind, but I think these two were a good start.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On Mar 1, 2008, at 1:52 AM, Joel Holdsworth wrote:

> How did you get inkscape to run under valgrind? When I tried it, it
> seemed to go wrong because the GC is incompatible.

_INKSCAPE_GC=disable valgrind --tool=memcheck ./inkscape

It won't really help find leaks, but uninitialized variables, etc.,  
should be caught

On Fri, 2008-02-29 at 16:13 -0600, Aaron Spike wrote:
> Ted Gould wrote:
> > Aaron, can you get the list of parameters passed again?  I think they
> > should be correct now...
> 
> So looks pretty good. I asked before if it was possible to put the 
> tempfile at the end of the arg list. Isn't that standard convention? I 
> think it will make it easier for any extensions that don't have robust 
> argv parsers. Also the first time I tried it I got a crash. oops.

I think the file should be at the end now.

What crashed?

		--Ted

Ted Gould wrote:
> I think the file should be at the end now.

Thanks!

> What crashed?

Not sure. :-( It was just a quick test at work and I didn't run in gdb. 
Seems to be something with the live preview, maybe?


I think I figured out what I find annoying about the live preview. The 
fact that it reruns during text box edits. Drop down lists and 
checkboxes make sense to force a rerun. But text boxes seem to be a bit 
clumsy. Sometimes a text box would work fine. If I'm typing a word to 
display I could see it regenerate an effect for each added character. 
But if the effect requires 5 characters and I hit backspace to change 
the final character, it runs and complains. Likewise in function 
plotter, if a function starts with "x" and I add "2" in front on the way 
to typing "2+x" I get a syntax error. Perhaps there should be a tag in 
the inx files that allows effect authors to specify textboxes where 
syntax matters and prevent rerunning the effect on every character 
change, maybe just on lost focus and enter. Thoughts?

Aaron Spike

Running win32 nightly build Inkscape0802291457.7z, it looks like both the
Measure Path and the Function Plotter are working perfectly, thanks a lot !!
They remember the parameter values and the parsing looks right.
There is something a bit unusual, namely I can run them once, not twice,
second time I seem to get no response.
However, that is a separate issue, this is the first time I've ever seen
them work, so I'm really impressed.

-Alvin

On Fri, 2008-02-29 at 13:40 -0800, Ted Gould wrote:
> On Fri, 2008-02-29 at 22:31 +0100, J.B.C.Engelen@... wrote:
> > For some reason, the function plotter does work for me now, most of 
> > the time. Sometimes it bugs, don't know why, but it crashes.
> > The GC::Anchored error message is always present though.
> 
> Is there a way I can use the logging mechanism to find out more about
> this.  I'm getting it also on some of the effects, I think only scripts,
> I'm unsure why.

It sounds like the problem is at least partly unbalanced anchor counts. 

Try setting the following environment variables accordingly and looking
at the debug output.

 INKSCAPE_DEBUG_LOG=debug.xml
 INKSCAPE_DEBUG_FILTER=REFCOUNT,EXTENSION,DOCUMENT

-mental

Ted Gould wrote:
> On Fri, 2008-02-29 at 22:31 +0100, J.B.C.Engelen@... wrote:
>    
>> For some reason, the function plotter does work for me now, most of
>> the time. Sometimes it bugs, don't know why, but it crashes.
>> The GC::Anchored error message is always present though.
>>      
>
> Mental,
>
> Is there a way I can use the logging mechanism to find out more about
> this.  I'm getting it also on some of the effects, I think only scripts,
> I'm unsure why.
>
> 		--Ted
>    


Ted,

Everyone should be using the g_something()  style of logging
messages, because glib allows us to hook into it and grab copies
of the msgs.   Anyone who does an assert() or printf() needs to
be shot.   :-)

But IF they do use the g_* messages, then we can grab and display them
in the Messages dialog.


bob

Ted Gould schrieb:
> On Fri, 2008-02-29 at 22:31 +0100, J.B.C.Engelen@... wrote:
>> For some reason, the function plotter does work for me now, most of 
>> the time. Sometimes it bugs, don't know why, but it crashes.
>> The GC::Anchored error message is always present though.
> 
> Mental,
> 
> Is there a way I can use the logging mechanism to find out more about
> this.  I'm getting it also on some of the effects, I think only
> scripts, I'm unsure why.
> 
> 		--Ted

Hi,

I'm having a input extension which works as external 
application. It works fine with inkscape 0.45.1 but 
doesn't  work with inkscape 0.46 preX. My application 
generate SVG to Stdout.  If  I use it in a windows shell 
and open the result in Inkscape 0.46pr2 and daily build 
it works, but no more as extension (inkscape crashes at 
this point). Is that an issue or are here changes in the 
configuration for external extensions?

Regards,
Simon

Simon Mieth wrote:
> I'm having a input extension which works as external 
> application. It works fine with inkscape 0.45.1 but 
> doesn't  work with inkscape 0.46 preX. My application 
> generate SVG to Stdout.  If  I use it in a windows shell 
> and open the result in Inkscape 0.46pr2 and daily build 
> it works, but no more as extension (inkscape crashes at 
> this point). Is that an issue or are here changes in the 
> configuration for external extensions?

We should probably start a new thread for this.

We need more information. You could be seeing one of two possible 
problems. A week or so ago I committed a one line fix to a bug that made 
extensions fail if they passed any binary data back to Inkscape on 
stdout. On vista there is an issue with the python environment that 
scripts see. This causes all python effects to fail.

Aaron

Aaron Spike schrieb:
> Simon Mieth wrote:
>> I'm having a input extension which works as external application. It 
>> works fine with inkscape 0.45.1 but doesn't  work with inkscape 0.46 
>> preX. My application generate SVG to Stdout.  If  I use it in a 
>> windows shell and open the result in Inkscape 0.46pr2 and daily build 
>> it works, but no more as extension (inkscape crashes at this point). 
>> Is that an issue or are here changes in the configuration for 
>> external extensions?
>
> We should probably start a new thread for this.
>
> We need more information. You could be seeing one of two possible 
> problems. A week or so ago I committed a one line fix to a bug that 
> made extensions fail if they passed any binary data back to Inkscape 
> on stdout. On vista there is an issue with the python environment that 
> scripts see. This causes all python effects to fail.
>
> Aaron
>
Hi Aaron,

I have a Java project which provides an API for parsing DXF and one part
for converting  this to SVG. The project includes a CLI tool like the
inkscape-dxf2svg tool. It takes the file and output all SVG
to  stdout.  If  I use  "mydxf2svg   c:\path\to\dxf > result.svg" in
Windows shell I can open the result in inkscape. With inkscape 0.45.1
and earlier it works with 0.46X not. I'm working for a new release and
want just to know if there is something changed so that have to change
my tool or is that an issue.
The extension can be build as java extension or as .NET extension and
both run in a Windows shell so it should not  be a path issue.
Windows XP SP2, Inkscape daily build from Feb 29 2008:
Java extension and .NET error message

         Microsoft Visual C++ Runtime Library
            Runtime Error!
            Inkscape internal error

My INX file:
<inkscape-extension>
    <_name>Kabeja DXF Input</_name>
    <id>org.kabeja.inkscape.import.dxf</id>
    <dependency type="extension">org.inkscape.input.svg</dependency>
    <param name="description" type="description">Choose the layout for
the import.</param>
    <param name="bounds-rule" gui-text="Layout" type="enum">
         <item>Modelspace</item>
         <item>Modelspace-Limits</item>
         <item>Paperspace</item>
         <item>Paperspace-Limits</item>
    </param>
    <input>
        <extension>.dxf</extension>
         <mimetype>application/dxf</mimetype>
        <_filetypename>Kabeja-AutoCAD DXF (*.dxf)</_filetypename>
        <_filetypetooltip>Import AutoCAD's Document Exchange
Format</_filetypetooltip>
        <output_extension>org.inkscape.output.svg</output_extension>
    </input>
    <script>
        <command reldir="extensions">kabeja-dxf2svg</command>
    </script>
</inkscape-extension>

So maybe something goes wrong with the pipe to inkscape.

Regards,
Simon

Simon Mieth wrote:
> Aaron Spike schrieb:
>> Simon Mieth wrote:
>>> Windows XP SP2, Inkscape daily build from Feb 29 2008:
>>> Java extension and .NET error message
>>>  
>>>         Microsoft Visual C++ Runtime Library
>>>            Runtime Error!            Inkscape internal error
>>
>> This must be a new issue. Could you please make a backtrace with gdb 
>> (there should be instructions on the wiki or website) and post a bug 
>> on launchpad?
>>
>> Aaron Spike
>>
> Ok I will try this.


Thanks