[CAD] Status
by Sebastian Götte
Hi,
this week I ironed out all crashes I could find and fixed the libavoid routing I recently broke. I fixed loading/saving of documents containing connectors and points (yay!) and back-ported the parts of the code that would need C++11 to compile to pre-C++11.
Tomorrow I will test more complicated libavoid routing and make a plan for object inclusion/exclusion selection and make a test build to verify everything works on a clean system followed by a few test runs inside valgrind. Remaining TODOs are icons for the toolbar buttons, undo handling, some more advanced point manipulation functions (mainly putting points in groups/taking them out of groups) and, finally, rebasing everything onto upstream. And there is the mystery of the lost cursor, but I think I'll figure that one out.
The current code can be found at [0].
Regards, Sebastian
[0] https://code.launchpad.net/~h-e-6/inkscape/connector-wip
9 years, 8 months
Re: [Inkscape-devel] Post-merge EMF work
by Krzysztof Kosiński
2013/8/30 mathog <mathog@...1176...>:
> Sure, but since dropping the libUEMF source files out of inkscape isn't
> going to be
> an option until distros start including it, there is no hurry.
OK. For now I'm going to put it in a separate directory, so that it
can be easily upgraded from the upstream version. I'll put the symbol
font conversion routines in the same directory, since this
functionality is closely related to EMF output. I don't know what to
do with 'libTERE' yet - I assume you mean the text_reassemble.[hc]
files in src/extension/internal.
By the way, it seems you haven't added yourself as an author to the
EMF output files which you significantly changed. Can I add your name
and e-mail there?
Regards, Krzysztof
9 years, 9 months
[CAD] Status
by Sebastian Götte
Hi,
this week I changed the SPPoint selection to use Inkscape's normal selection mechanics instead of the control-point-selection.cpp. This has the advantage that selecting points and connectors at the same time is not quite as bad a hack as it would be otherwise.
Doing this I introduced a new signal for selection/deselection in SPObject.
I also changed the UI a lot to make it possible to reconnect connectors. SPPoints are now created by shift-clicking into the document while the selection is empty. If the selection is not empty, shift-click toggles the selection of the object under the cursor. Control-click should work as expected with groups. Connectors are terminated by clicking on the end point or somewhere in empty space (in which case a new SPPoint will be created on the clicked location).
Sometimes stray points still appear because I have not yet found out how to delete SPPoints without crashing Inkscape. I am working on that.
Connector deletion appears to work now. SPPoint deletion still has its issues. After deleting a SPPoint, Inkscape crashes with ominous memory corruption errors. I was unable to find the cause of that so far.
I will push a commit later that allows easy reproduction of this.
Sebastian
9 years, 9 months
DialogScript message
by mathog
Just built branch lp988601 for the first time since Kris merged in
changes from Trunk on 8/16. It seems to work fine, but there is a new
message at the beginning:
Unable to find: DialogScript
** (inkscape:14139): WARNING **: Unknown verb name: DialogScript
Is that something old that has been partly removed, or is it something
new that has been partly implemented?
On the bzr update there was a warning that src/extension/script could
not be removed because it was
not empty. Related to this message?
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 9 months
[Inskscape-devel] [Recolor] Good News after long
by Arshdeep Singh
Hi all,
I was able to spot the reason for the crashes. It was the type-casting that
was causing a pointer nullification. With a few modifications I was able to
fix that I got to render the nodes onto the wheel.
Its just time to play with signals and xml stuff now. :)
Here's a screenshot for interested folks:
[image: Inline image 1]
--
Arshdeep Singh
Third Year, Computer Engineering
Delhi Technological University
Ph: +91-9654115614
https://sites.google.com/site/adsingh1729/home
9 years, 9 months
Rethinking revision 12471
by mathog
I recently became aware of revision 12471, and overall, I am afraid
that the way in which it was implemented is
detrimental to the readability and future maintenance of the Inkscape
code. Presumably the underlying function it
implements is to allow changes in the ratio PX/IN, and other units of
measurement, and I
have no issue with that goal. However, prior to 12471 all of the unit
relationships were neatly set up in a set of defines in
src/unit-constants.h which defined things like PX_PER_IN which were used
elsewhere in the code. These evaluated
to static values, and the new ones do not, but that does not negate the
usefulness of the define.
12471 removes all of these defines and makes substitutions throughout
the code where
PX_PER_IN
is replaced by
Inkscape::Util::Quantity::convert(1, "in", "px")
My first criticism is that the new quantity is at first glance,
indeterminate. Is it converting IN to PX or vice versa, what
does "1" do?
My second criticism is that eliminating the defines results in hundreds
of substitutions in 12471 that are entirely unnecessary. All that was
required was to change the defines in src/unit-constants.h, for instance
from
#define PX_PER_IN (PT_PER_IN / PT_PER_PX)
to
#define PX_PER_IN Inkscape::Util::Quantity::convert(1, "in", "px")
after which virtually no changes elsewhere in the code are required.
By doing that, the existing and
relatively clear code, like:
p0[X] = (p0[X] * IN_PER_PX * dwDPI);
need not become the obfuscated (to my mind) form:
p0[X] = (p0[X] * Inkscape::Util::Quantity::convert(1, "px", "in") *
dwDPI);
Before 12471 PX_PER_IN already evaluated to a complex expression, and
the whole point of the define was
to let the compiler handle that mess and only present to the programmer
a short easily understood term. 12471 is a step backwards in this
regard.
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years, 9 months
Fwd: Modifications to RecolorWheelPrivate
by Krzysztof Kosiński
2013/8/27 Arshdeep Singh <moduli16@...400...>:
> I added:
> new (&(priv->nodes)) std::map<std::string,RecolorWheelNode>();
> to recolor_wheel_init (RecolorWheel *wheel) .
>
> Honestly I have never seen this style of code, so I really don't understand
> what it does. The good news is it does get to run the dialog box of 'Recolor
> Artwork' i.e. no error while the dialog is loaded, but the moment I draw a
> shape (active selection) the application crashes.
This 'style of code' is known as 'placement new' and it calls the
constructor of an object with an explicit 'this' pointer. It needs to
be used when memory for an object is allocated from a different source
than operator new.
In normal C++, placement new is rarely used, because objects are
typically allocated and constructed at the same time with operator
new. However, if you allocate memory from a different source (in this
case from GObject), you need to call the constructor yourself.
http://en.wikipedia.org/wiki/Placement_syntax
> Also my init function looks like this (for a quick browse, if needed):
>
> static void
> recolor_wheel_init (RecolorWheel *wheel)
> {
>
> RecolorWheelPrivate *priv;
>
> priv = G_TYPE_INSTANCE_GET_PRIVATE (wheel, RECOLOR_TYPE_COLOR_WHEEL,
> RecolorWheelPrivate);
>
> wheel->priv = (RecolorWheelPrivate*)priv;
> priv = (RecolorWheelPrivate*)wheel->priv ;
What is the point of the last line? Why the casts? They are unnecessary.
> What I don't undersytnd is how to initilaize a static object.
> RecolorWheelPrivate has other static members like :
What exactly do you mean by "static members"? The structure you
provided does not define any static members.
> gdouble h,s,v don't need explicit initializers. Why so ? Is it that the only
> map object requires an explicit initilization. If so, why ?
'gdouble' is a primitive type (a typedef of 'double') which doesn't
have any constructors. GObject zeroes memory by default, so if you
don't assign to h, s, v they are left as all zeroes, which corresponds
to the double value of 0.0.
Regards, Krzysztof
9 years, 9 months
XDG Templates
by Martin Owens
I was reviewing the templates work by Jan Darowski and it got me
thinking about the FreeDesktop.org XDG spec; it has a provision for a
templates directory that we should be using instead of (or as well as)
~/.config/inkscape/ which is hidden from the user.
This only applies to FreeDesktops/XDG complient desktops. But it would
be useful.
http://freedesktop.org/wiki/Software/xdg-user-dirs/
Example:
XDG_TEMPLATES_DIR="$HOME/Templates"
Thoughts?
9 years, 9 months
Re: [Inkscape-devel] Modifications to RecolorWheelPrivate
by Arshdeep Singh
Hi,
Recap: I made a separate container for RecolorWheel.
Initially there was an initialization error that crashed the application.
As pointed out by Krzysztof, the std::map<std::string, RecolorWheelNode>
had to be explicitly initialized which made the crash go away. The Recolor
Dialog box renders perfectly. Invoking the DialogBox in Inkscape was
causing a crash (before the explicit initialization of map) .
Unfortunately, the application still crashes when I draw a new object on
the canvas. Basically the crash happens when I select an object on the
canvas.
I was debugging the errors in gdb using g_message but here is the tricky
part:
When I run the inkscape.exe without gdb the application crashes only when
the RecolorArtwork Dialog is active and an object on the canvas is
selected. But, in gdb the application starts constantly giving the warning:
" HEAP: Free heap block a90b8f6 modified at a90b8f6 after it was freed. "
As a result the application doesn't get to the point where I can invoke
RecolorArtwork and debug it.
My latest branch can be found at:
https://code.launchpad.net/~moduli16/inkscape/recolor .
Regards,
Arshdeep
On Wed, Aug 28, 2013 at 2:38 AM, Arshdeep Singh <moduli16@...400...> wrote:
> By static I meant 'non pointer' variables. Okay so this doesn't seem to be
> the problem causing the crash. Gdb ends up showing the same heap error I
> started this thread with. Can you spot an error as to why that keeps
> happening ?
> On Aug 28, 2013 2:25 AM, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
>
>> 2013/8/27 Arshdeep Singh <moduli16@...400...>:
>> > I added:
>> > new (&(priv->nodes)) std::map<std::string,RecolorWheelNode>();
>> > to recolor_wheel_init (RecolorWheel *wheel) .
>> >
>> > Honestly I have never seen this style of code, so I really don't
>> understand
>> > what it does. The good news is it does get to run the dialog box of
>> 'Recolor
>> > Artwork' i.e. no error while the dialog is loaded, but the moment I
>> draw a
>> > shape (active selection) the application crashes.
>>
>> This 'style of code' is known as 'placement new' and it calls the
>> constructor of an object with an explicit 'this' pointer. It needs to
>> be used when memory for an object is allocated from a different source
>> than operator new.
>>
>> In normal C++, placement new is rarely used, because objects are
>> typically allocated and constructed at the same time with operator
>> new. However, if you allocate memory from a different source (in this
>> case from GObject), you need to call the constructor yourself.
>>
>> http://en.wikipedia.org/wiki/Placement_syntax
>>
>> > Also my init function looks like this (for a quick browse, if needed):
>> >
>> > static void
>> > recolor_wheel_init (RecolorWheel *wheel)
>> > {
>> >
>> > RecolorWheelPrivate *priv;
>> >
>> > priv = G_TYPE_INSTANCE_GET_PRIVATE (wheel, RECOLOR_TYPE_COLOR_WHEEL,
>> > RecolorWheelPrivate);
>> >
>> > wheel->priv = (RecolorWheelPrivate*)priv;
>> > priv = (RecolorWheelPrivate*)wheel->priv ;
>>
>> What is the point of the last line? Why the casts? They are unnecessary.
>>
>> > What I don't undersytnd is how to initilaize a static object.
>> > RecolorWheelPrivate has other static members like :
>>
>> What exactly do you mean by "static members"? The structure you
>> provided does not define any static members.
>>
>> > gdouble h,s,v don't need explicit initializers. Why so ? Is it that the
>> only
>> > map object requires an explicit initilization. If so, why ?
>>
>> 'gdouble' is a primitive type (a typedef of 'double') which doesn't
>> have any constructors. GObject zeroes memory by default, so if you
>> don't assign to h, s, v they are left as all zeroes, which corresponds
>> to the double value of 0.0.
>>
>> Regards, Krzysztof
>>
>
--
Arshdeep Singh
Third Year, Computer Engineering
Delhi Technological University
Ph: +91-9654115614
https://sites.google.com/site/adsingh1729/home
9 years, 9 months
