display/sodipodi-ctrl.cpp
by Johan Engelen
Hi all,
Hope that someone who knows a bit about /src/display/sodipodi-ctrl
can help me with these lines:
for (y = 0; y < side; y++){
px = reinterpret_cast<guint32*>(data + y * r);
for (x = 0; x < side; x++) {
*p++ = *px++;
}
}
The "px++" is not necessary right? Should just be "px" the way I see it.
(while fixing it, please also reduce the scope of px)
Thanks,
Johan
9 years, 9 months
[CAD] Status
by Sebastian Götte
Hi,
I just pushed some changes to launchpad that fix the GObject instantiation problem I had [0]. I am now explicitely initializing the members to 0. Next comes some cleanup integrating the feedback I received.
The current code allows one to place SPPoints and SPConnectors in the document, the three major problems left are state handling in the ConnectorContext (dragging does not work yet), live preview (the "red curve" is not displayed/updated yet) and a missing/superfluous display->doc transform.
I just finished moving into a new flat so I did not spend a lot of the last few days at my computer.
Best regards,
Sebastian
[0] https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/files/
9 years, 9 months
Re: [Inkscape-devel] GObject removal branch
by Markus Engel
Hi,
I'm on vacation from now until (probably) August 21. Thus, I may be able to
answer e-mails but I can't work on my branch actively.
I opened a merging proposal on launchpad.
Maybe any of you can have a look at it and, if no other critical bugs
appear, merge it?
Regards,
Markus
9 years, 10 months
floating dialog transient behavior
by Johan Engelen
Hi all,
I came across this code:
void
FloatingBehavior::onDesktopActivated (SPDesktop *desktop)
{
Inkscape::Preferences *prefs = Inkscape::Preferences::get();
gint transient_policy =
prefs->getIntLimited("/options/transientpolicy/value", 1, 0, 2);
#ifdef WIN32 // Win32 special code to enable transient dialogs
transient_policy = 2;
#endif
Why is transient_policy hard-coded to 2 on Windows? And why not just set
the transient_policy option to 2 per default for Windows?
Thanks,
Johan
9 years, 10 months
memset on SPStyle
by Johan Engelen
Hi all,
I just came across this piece of code:
memset(style, 0, sizeof(SPStyle));
That looks terrifying! SPStyle is a huge struct, containing member
objects (sigc::connection) besides just simple integers and enums.
CPPCheck complains with "Using 'memset' on struct that contains a
virtual method.". I can't find any virtual methods in SPStyle, but still
it looks like a bad bug.
I have disabled that line of code, and added extra re-init lines in
r12452. Please have a look and confirm the fix.
Thanks,
Johan
9 years, 10 months
[Tracing] Library integration/API design
by Vinícius dos Santos Oliveira
So, I reached a point where I know how the next steps can be
implemented, but, differently from before, the next steps on
libdepixelize can have a big impact on how it will be integrated on
Inkscape. I decided it would be a good thing to discuss this matter with
other developers.
Currently it's possible to represent simple paths on libdepixelize (see
this), but to implement the full Kopf-Lischinski algorithm, I'll need to
have paths with "holes" and I'll need to use complex path
representations with enough expressive power to communicate things like
"point start in A, then do a Bézier to C...". I don't want to create a
new interface to represent paths, because this interface already exists
and it's called SVG.
Anyway, I'm sending this message now, but I'll look deeper in Inkscape
code and come up with some design ideas later.
--
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker
9 years, 10 months
Automatic tests now in PPA
by Alex Valavanis
Dear All,
I have enabled automatic testing (make check) in the trunk PPA, so
we'll now have an early warning system for runtime errors. Please can
I draw your attention to the known test failures [1]:
#1202271 cxxtest: preferences-test.h fails
#1208002 cxxtest: svg-length-test.h fails (in progress)
#1208005 cxxtest: svg-path-geom-test.h fails
#1208013 cxxtest: curve-test.h fails
#1207502 cxxtest: svg-affine-test.h fails
At the moment, PPA builds will (correctly) fail if the extension tests
fail, but will still succeed in the case of errors in Inkscape itself
until we fix *all* of the broken tests above.
It therefore makes sense to try to fix all of these in time for
Inkscape 0.49 so that we have a correctly functioning unit test
system. If no one objects, I'll target all of those bugs to Inkscape
0.49.
Thanks,
AV
[1] https://bugs.launchpad.net/inkscape?field.searchtext=cxxtest&search=Searc...
9 years, 10 months
Re: [Inkscape-devel] GObject removal branch
by Markus Engel
>> So far, only the crash with the text tool can be reproduced
>> consistently (after 4 or at most ~8 times tapping the space bar).
>>
>> However, with some patience I'm able to make your branch crash when
>> tool-switching with other tools as well:
>
>The backtrace looks like a double-free. There could be some leftover manual calls to member constructors / destructors in InkNodeTool >and SPTextContext.
>
>Regards, Krzysztof
Hm, I didn't find any, but I'm sure this has got to do with the way I rewrote the part that switches the tools, see src/desktop.cpp:675.
The old method is right underneath it, commented out. I reordered it, maybe this will help. Could you try it out once more?
If you just comment out line 691 ("delete ec_old;"), does it still crash?
Regards,
Markus
9 years, 10 months
2 questions: Walk through all nodes and the two "different trees" SPObject/agnostic XML
by Christoffer Holmstedt
I'm trying to walk through a complete document and get all nodes of a
specific type, in this case <metadata> to populate the new metadata GUI.
My best bet now is to get the current active SPDocument and start to
iterate from the root node, depth-first. I've found the sp_repr_lookup_name
in "src/xml/repr.h" which do exactly that but stops at the first hit so I
would have to wrap it somehow and run it multiple times. If I've understood
this correctly it will work on the agnostic XML backbone and not with
SPObjects which I should be using but then again RDF implementation doesn't
use SPObject in its current state. Am I on the right track or totally lost?
(within repr-util.cpp it seems like you can iterate through a XML::Node's
all children with the help of firstChild() and next(), perhaps better than
using the c facade function, but will it work with RDF nodes?)
So to my second part, somewhat related, In sp-object.h a comment says
"[...] SPObject layer is bound to the SPRepr layer, closely following the
SPRepr mutations via callbacks." We have the typed object layer with
SPObjects and the agnostic XML layer with SPRepr. The confusion for me now
is concerning variable naming, I think, throughout Inkscape codebase both
"repr" and "node" are used as variable names for XML::Node objects.
Is SPRepr the old "name" for XML::Node?
If yes, this would mean that everything below Inkscape::XML do work on the
the agnostic XML backbone layer and not the SPObjects, have I understood
this correctly?
Regards
--
Christoffer Holmstedt
9 years, 10 months
GObject removal branch
by Krzysztof Kosiński
2013/7/31 Markus Engel <p637777@...1081...>:
>> However, using it would require you to rewrite the init functions of all
> SPObjects.
> ...
>> Replacing GObject-style initialization with constructor / destructor
> shims in the style of NRObject would considerably simplify removing
> the GObject dependency later and reduce the burden of maintaining the
> init / dispose functions.
>
> Well, please don't do that, I'm already done removing the GObject
> dependency, take a look at my branch at
> https://code.launchpad.net/~engelmarkus/inkscape/cppify .
Some review comments about this branch
1. The code seems wrong in a several places. For example, the
constructor of SPObject retains the manual constructor calls and its
destructor retains the manual destructor calls. Member initialization
is already done before the constructor is even entered, and member
destruction happens automatically after the destructor returns. I'm
fairly sure this will lead to problems at runtime.
2. A lot of the constructor code should be changed to member
initializers. See e.g. the constructor of SPItem.
3. Class names such as CSomething are reminiscent of MFC. The prefixes
should be removed and the classes put in namespace Inkscape::SVG
(since they represent objects in the SVG).
4. "#pragma once" is not used in existing Inkscape code. For
consistency you should use standard include guards.
5. singleton.h should be merged into sp-factory.h. Singletons should
be avoided where possible, so a separate singleton header is not a
good idea. Boost doesn't have a singleton header for the same reason.
6. Method and variable names are not consistent with our coding style,
though this could be addressed later since it's a leftover of previous
GObject code.
http://staging.inkscape.org/en/develop/coding-style/
http://inkscape.org/doc/coding_style.php (old website)
7. The virtual methods should be made protected, since they are not
intended for use outside of SP node implementations.
Since the initialization rework I proposed would address points 1 and
2, it seems that this part of the work is actually not done.
What do others think? Should we work from Markus' code or rewrite the
initialization first? Should we release 0.49 before introducing this
kind of changes?
Regards, Krzysztof
9 years, 10 months
