Inkscape

On 30-06-11 02:51, Gellule Xg wrote:
> I would like to draw your attention on this 2geom commit:
> http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10385
> Should this be pushed to 2geom? I'm not too happy with the solution I 
> chose for fixing part c) of this bug:
> https://bugs.launchpad.net/inkscape/+bug/640985

How does a little instability cause a crash? Weird results, okay, but a
crash? As far as I'm concerned your change is a bit dubious, but
pragmatic and commonplace, but it should not solve a crash. So can you
explain what causes the crash?

On 6/29/11 8:58 PM, Jasper van de Gronde wrote:
> On 30-06-11 02:51, Gellule Xg wrote:
>> I would like to draw your attention on this 2geom commit:
>> http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10385
>> Should this be pushed to 2geom? I'm not too happy with the solution I
>> chose for fixing part c) of this bug:
>> https://bugs.launchpad.net/inkscape/+bug/640985
> How does a little instability cause a crash? Weird results, okay, but a
> crash? As far as I'm concerned your change is a bit dubious, but
> pragmatic and commonplace, but it should not solve a crash. So can you
> explain what causes the crash?
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Jasper,

Connector-avoid is set on a circle. The circle is approximated by a set 
of points where two points are exactly at the same location (first one & 
last one). This seems to be because a circle is something like four 
90deg arcs plus a straight line of length 0 to connect them. Now, when 
you move the circle around depending on the result of the transformation 
applied, the first and last points can be exactly at the same location 
or at slightly (epsilon) different locations. This causes the number of 
point making the convex for the circle to be variable of +/-1 point. The 
libavoid code does not accept this change.

Ah, ah. I should not have said crash, more the emission of an assertion 
by the libavoid code, reacting to this number of point change.

Hoping, I make sense...

Maybe making libavoid accept such a change would be a better solution.

-Julien

---- Gellule Xg <gellule.xg@...> wrote: 
> I would like to draw your attention on this 2geom commit:
> http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10385
> Should this be pushed to 2geom? 

If you make changes to our 2geom copy, they will most probably be lost on the next 2geom update. So in general, yes you should push your changes to 2geom's repository too.

Specifically about your change; on quick inspection, the " == 0" seems wrong. In 2geom we use "are_near" to check whether floating point values are the same. I remember that the are_near methods use 2geom's default 'nearness' range of 1e-8.

Ciao,
  Johan

On 6/30/11 8:04 PM, Michael Wybrow wrote:
> On 30/06/2011, at 5:25 PM, Gellule Xg wrote:
>
>> Connector-avoid is set on a circle. The circle is approximated by a set
>> of points where two points are exactly at the same location (first one&
>> last one). This seems to be because a circle is something like four
>> 90deg arcs plus a straight line of length 0 to connect them. Now, when
>> you move the circle around depending on the result of the transformation
>> applied, the first and last points can be exactly at the same location
>> or at slightly (epsilon) different locations. This causes the number of
>> point making the convex for the circle to be variable of +/-1 point. The
>> libavoid code does not accept this change.
>>
>> Ah, ah. I should not have said crash, more the emission of an assertion
>> by the libavoid code, reacting to this number of point change.
>>
>> Hoping, I make sense...
>>
>> Maybe making libavoid accept such a change would be a better solution.
>
> The libavoid shape movement/resize code probably shouldn't have required the polygon passed to setNewPoly to have the same number of points.  This was just an assumption when I wrote the original code.  In the new interface, this method doesn't exist anymore and you can move (or resize) a polygon by passing the x and y distance moved, or just giving an updated (and possibly complete new) polygon.  Hence this assertion problem will go away when I update the libavoid version in Inkscape (this was waiting on some code that was not available in the new version of libavoid, but now is, but still will require a few changes to the way Inkscape calls libavoid).
>
> Gellule, if this is still not fixed with your other changes, and it's needed for the upcoming point release, then I could rewrite setNewPoly to accept a different number of points.  It only has that assertion now because it reused the same memory and rewrites the points, rather than recreating the shape.
>
>
> Cheers,
> Michael
>
Most of the issues I was looking into are now addressed. Both the 
copy/paste, and the move issues are related to this setNewPoly 
limitation, therefore the best thing to do would be to try reverting my 
fixes as soon as your new version is in place. No pressure for 0.48.2. :)
-Julien/Gellule

Hi,

there is no Problem with R10386 on Win7. Maybe it's a problem with a 
certain or special theme on XP?

Sincerely,

UweSch

Am 29.06.2011 15:58, schrieb LucaDC:
> Sorry for insisting on this. I know it's a minor issue, but I just wanted to
> understand if it's intended or not. Should I open a "bug"(?) report about
> it?
> Regards.
>

Uwe Schöler - OSS-Marketplace.com wrote:
> 
> Hi,
> 
> there is no Problem with R10386 on Win7. Maybe it's a problem with a 
> certain or special theme on XP?
> 
> Sincerely,
> 
> UweSch
> 
Thank you for the reply.
Indeed, I use Windows XP's Classical theme (old Windows 95/98/2000) and
after your suggestion I verified that with the "new" XP theme the sliders
are ok.
Anyway, I'm having this "problem" only since not so many revisions (I
couldn't say which one): I've always had correct sliders before.
Hence I think we should consider this a "bug".

-- 
View this message in context: http://old.nabble.com/Black-background-in-active-sliders-tp31859141p31960836.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On Thu, Jun 30, 2011 at 12:25 AM, LucaDC <dicappello@...:

>
>
> Uwe Schöler - OSS-Marketplace.com wrote:
> >
> > Hi,
> >
> > there is no Problem with R10386 on Win7. Maybe it's a problem with a
> > certain or special theme on XP?
> >
> > Sincerely,
> >
> > UweSch
> >
> Thank you for the reply.
> Indeed, I use Windows XP's Classical theme (old Windows 95/98/2000) and
> after your suggestion I verified that with the "new" XP theme the sliders
> are ok.
> Anyway, I'm having this "problem" only since not so many revisions (I
> couldn't say which one): I've always had correct sliders before.
> Hence I think we should consider this a "bug".
>

Well, the thing that needs to be identified though is where the bug exists.
Is this actually an Inkscape bug? It seems more likely to me that the bug is
either in that theme or in the newer version of GTK in our devlibs. Note, by
saying it could be the theme I mean it could just not have been updated with
more recent changes to GTK as it might have needed to be.

Cheers,
Josh

Josh Andler wrote:
> 
> Well, the thing that needs to be identified though is where the bug
> exists.
> Is this actually an Inkscape bug? It seems more likely to me that the bug
> is
> either in that theme or in the newer version of GTK in our devlibs. Note,
> by
> saying it could be the theme I mean it could just not have been updated
> with
> more recent changes to GTK as it might have needed to be.
> 
Sorry but I think I missed the point.
Which "theme" do you refer to? I assume you are not speaking about Windows
XP's Classic theme as it's been there since ages and sure doesn't need any
update to GTK (or if you think so you may contact Microsoft and let them
know ;)
So, probably you are speaking about Inkscape's theme, which I've never
changed from sources (rev. 10391); but as I don't know how to change it,
maybe I've got something wrong on my system without knowing. I've tried with
fresh preferences (which is the only file I have not taken from sources,
apart from a couple of lines added to /share/keys/default.xml) but the
problem is still there. Anyway, it sounds weird that changing Windows' theme
the problem changes too.
As for devlibs, I'm up with rev. 24 (the latest).
Is there something I can check to better understand where the problem starts
from?
-- 
View this message in context: http://old.nabble.com/Black-background-in-active-sliders-tp31859141p31964362.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On Thu, Jun 30, 2011 at 8:51 AM, LucaDC <dicappello@...:

>
>
> Josh Andler wrote:
> >
> > Well, the thing that needs to be identified though is where the bug
> > exists.
> > Is this actually an Inkscape bug? It seems more likely to me that the bug
> > is
> > either in that theme or in the newer version of GTK in our devlibs. Note,
> > by
> > saying it could be the theme I mean it could just not have been updated
> > with
> > more recent changes to GTK as it might have needed to be.
> >
> Sorry but I think I missed the point.
> Which "theme" do you refer to? I assume you are not speaking about Windows
> XP's Classic theme as it's been there since ages and sure doesn't need any
> update to GTK (or if you think so you may contact Microsoft and let them
> know ;)
>

I was under the impression that GTK had a different theme it used when using
the classic Windows GTK theme (and it sounds like I may be off the mark on
that).

As for devlibs, I'm up with rev. 24 (the latest).
> Is there something I can check to better understand where the problem
> starts
> from?
>

It seems likely that it may have to do with something that has changed with
GTK somewhere between what we had before and the version we have now. The
only way I can think to test/check where things went wrong is to download
other GTK binaries between what we had before and what we have now until you
find one that doesn't show the issues and work up from there until you can
identify when it broke.

Cheers,
Josh

Josh Andler wrote:
> 
> It seems likely that it may have to do with something that has changed
> with
> GTK somewhere between what we had before and the version we have now. The
> only way I can think to test/check where things went wrong is to download
> other GTK binaries between what we had before and what we have now until
> you
> find one that doesn't show the issues and work up from there until you can
> identify when it broke.
> 
Mmmh, actually I rely on the devlibs repository for all updates of such
libraries.
I can see that in rev.22 there has been an update to GTK 2.22 and Glib 2.26.
The preceding one was in January (update to Cairo 1.10.2) and I feel that
the problem was not present so far ago.
The rev.22 update has been quite massive so I don't think I'll be able to
make small steps back.
-- 
View this message in context: http://old.nabble.com/Black-background-in-active-sliders-tp31859141p31965077.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On Thu, Jun 30, 2011 at 10:16 AM, LucaDC <dicappello@...:

>
>
> Josh Andler wrote:
> >
> > It seems likely that it may have to do with something that has changed
> > with
> > GTK somewhere between what we had before and the version we have now. The
> > only way I can think to test/check where things went wrong is to download
> > other GTK binaries between what we had before and what we have now until
> > you
> > find one that doesn't show the issues and work up from there until you
> can
> > identify when it broke.
> >
> Mmmh, actually I rely on the devlibs repository for all updates of such
> libraries.
> I can see that in rev.22 there has been an update to GTK 2.22 and Glib
> 2.26.
> The preceding one was in January (update to Cairo 1.10.2) and I feel that
> the problem was not present so far ago.
> The rev.22 update has been quite massive so I don't think I'll be able to
> make small steps back.
>

Correct, the problem was probably not present at that time. However, a minor
graphical glitch which will be present on a minority of Windows boxes is far
less of an issue than a security exploit with gtk that was present on all
Windows boxes.

This may be one of those issues where if you're not willing to do the leg
work and test, then no one probably will.

Cheers,
Josh

0.48.1 has been out since March... I think I'm not understanding your
question.

Cheers,
Josh

On Wed, Jun 29, 2011 at 1:56 PM, John Culleton <john@...:

> **
>
> I know that 48.2 is now the current development product. But are there any
> show stoppers in 48.1?
>
> --
>
> John Culleton
>
> "Death Wore Black" Police procedural: http://www.deathworeblack.com/
>
> "Create Book Covers with Scribus"
>
> http://booklocker.com/books/4055.html
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>

Hi,

Did you in any way check this against GDL trunk? The current goal is to get
2.30 compatible and then to switch to 3.x from my understanding...

Cheers,
Josh

On Wed, Jun 29, 2011 at 2:43 AM, Jon Cruz <jon@...> wrote:

> Hi,
>
> in clearing up some warnings, I (as somewhat expected) spotted a potential
> issue hiding amongst the others.
>
> libgdl/gdl-dock-item-grip.c: In function 'gdl_dock_item_grip_expose':
> libgdl/gdl-dock-item-grip.c:143: warning: assignment from incompatible
> pointer type
> libgdl/gdl-dock-item-grip.c:146: warning: passing argument 2 of
> 'gdk_draw_rectangle' from incompatible pointer type
>
>
> If anyone wants something to poke at a bit, checking this might be good.
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

The warning refers to a line in the focus-handling patch that was
added in Inkscape... it is not present in GDL trunk.  The line in
question sets the colour of the dock item handle depending on whether
the dock item has focus or not.  I can hopefully have a look at it
later.

Really, we need to find a different way of indicating focus... I seem
to remember that the handle-drawing code has changed quite a bit
upstream, to make use of Cairo bindings.

AV

On 29 June 2011 10:47, Josh Andler <scislac@...> wrote:
> Hi,
>
> Did you in any way check this against GDL trunk? The current goal is to get
> 2.30 compatible and then to switch to 3.x from my understanding...
>
> Cheers,
> Josh
>
> On Wed, Jun 29, 2011 at 2:43 AM, Jon Cruz <jon@...> wrote:
>>
>> Hi,
>>
>> in clearing up some warnings, I (as somewhat expected) spotted a potential
>> issue hiding amongst the others.
>>
>> libgdl/gdl-dock-item-grip.c: In function 'gdl_dock_item_grip_expose':
>> libgdl/gdl-dock-item-grip.c:143: warning: assignment from incompatible
>> pointer type
>> libgdl/gdl-dock-item-grip.c:146: warning: passing argument 2 of
>> 'gdk_draw_rectangle' from incompatible pointer type
>>
>>
>> If anyone wants something to poke at a bit, checking this might be good.
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Inkscape-devel mailing list
>> Inkscape-devel@...
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>

Fixed in trunk r10390.

Next job is to replace the use of the deprecated gdk_draw_rectangle symbol!

AV

On 29 June 2011 18:50, Alex Valavanis <valavanisalex@...> wrote:
> The warning refers to a line in the focus-handling patch that was
> added in Inkscape... it is not present in GDL trunk.  The line in
> question sets the colour of the dock item handle depending on whether
> the dock item has focus or not.  I can hopefully have a look at it
> later.
>
> Really, we need to find a different way of indicating focus... I seem
> to remember that the handle-drawing code has changed quite a bit
> upstream, to make use of Cairo bindings.
>
> AV
>
> On 29 June 2011 10:47, Josh Andler <scislac@...> wrote:
>> Hi,
>>
>> Did you in any way check this against GDL trunk? The current goal is to get
>> 2.30 compatible and then to switch to 3.x from my understanding...
>>
>> Cheers,
>> Josh
>>
>> On Wed, Jun 29, 2011 at 2:43 AM, Jon Cruz <jon@...> wrote:
>>>
>>> Hi,
>>>
>>> in clearing up some warnings, I (as somewhat expected) spotted a potential
>>> issue hiding amongst the others.
>>>
>>> libgdl/gdl-dock-item-grip.c: In function 'gdl_dock_item_grip_expose':
>>> libgdl/gdl-dock-item-grip.c:143: warning: assignment from incompatible
>>> pointer type
>>> libgdl/gdl-dock-item-grip.c:146: warning: passing argument 2 of
>>> 'gdk_draw_rectangle' from incompatible pointer type
>>>
>>>
>>> If anyone wants something to poke at a bit, checking this might be good.
>>>
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> _______________________________________________
>>> Inkscape-devel mailing list
>>> Inkscape-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Inkscape-devel mailing list
>> Inkscape-devel@...
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>>
>>
>

On 27-06-11 23:16, Abhinav Vishwa wrote:
>>> I have compiled Inkscape completely according to instructions given on
>>> this link
>>> http://wiki.inkscape.org/wiki/index.php/Win32Port
>>>
>>> but as given there is no  executable in the inkscape directory.
>>>
>>> That's why nsis installer is also giving error in creating installer.
>>
>> Just a few more details could help. What exactly did you do, and what
>> was the result? In particular, where there any errors during
>> compilation? (Compilation should end with a whole lot of things being
>> copied and then showing the total amount of time spent on the
>> compilation.) Did you make sure that you have both devlibs and trunk,
>> and that the paths in mingwenv.bat point to the right locations? Are you
>> using TDM's gcc? Have you built buildtool? Do you get a build directory?
>> If so, what does it contain? Etc., etc.
> 
> I did each and every step as given on the link , I've provided.
> There weren't any error's in the compilation.
> yes, I've both devlibs and trunk and here is the mingwenv.bat
> 
> @echo Setting environment variables for MinGw build of Inkscape
> IF "%DEVLIBS_PATH%"=="" set DEVLIBS_PATH=c:\devlibs
> IF "%MINGW_PATH%"=="" set MINGW_PATH=c:\MinGW
> set MINGW_BIN=%MINGW_PATH%\bin
> set PKG_CONFIG_PATH=%DEVLIBS_PATH%\lib\pkgconfig
> set PATH=%MINGW_BIN%;%PATH%;%DEVLIBS_PATH%\bin;%DEVLIBS_PATH%\pytho
> 
> which points to the right locations.

Okay, if you did exactly what's on that page and everything worked fine
then you should have an inkscape subdirectory containing inkscape.exe,
as this is one of the steps in the build procedure (and failing to copy
files to this directory would generally show up as an error).

To clarify, suppose that you have a directory called "trunk" that
contains the source code (so it contains buildtool.cpp, mingwenv.bat,
the src and share directories, etc.), then a subdirectory "inkscape" of
the trunk directory should be created (so at the same level as the src,
share and build directories) and it should contain a whole lot of files,
including inkscape.exe. So schematically you should have something like
this:

trunk
 - build
 - inkscape
    - inkscape.exe
    - ...
 - share
 - src
 - mingwenv.bat
 - build.xml
 - buildtool.cpp
 - ...

You run buildtool in the "trunk" directory.

If you still cannot find inkscape.exe, please send the output of
buildtool and of dir /s, executed from the "trunk" directory (if it's
large, please zip and mail to me personally or put it on-line somewhere).

Mon, 27 Jun 2011 18:00:45 -0400
Martin Owens <doctormo@...> kirjoitti:

> On Thu, 2011-06-23 at 11:05 -0500, Ted Gould wrote:
> > and
> > there's some question of whether code can be put into the public
> > domain.   
> 
> IANAL but I don't think that's true. Anything that can have copyright
> and thus an owner, can have a public domain declaration and thus be in
> the public domain.

Maybe... Wherever the concept of placing your work in public domain
exists.

There's a some explanation at
http://wiki.creativecommons.org/Public_domain

-- 
Niko Kiirala