[Recolor] Week #3: Moving onto Further Tasks
by Arshdeep Singh
Hello all,
Because I'd been stuck on the second goal for so long, I decided to get on
to write the GUI subsytem, which was actually my third and final task for
the midterm evaluation. I have written the paint_recolor_nodes( ) function
successfully. Here is a screenshot:
[image: Inline image 1]
The black outlined, white colored (with color inside) are the intended
nodes that will function in the final render. Now I'll move onto writing
the events that trigger repainting and node dragging. I cannot work on
these events making actual changes till the brick-wall issues are resolved.
My mentor has promised he'll look into it by this weekend. :)
Till then those tasks are deferred.
--
Arshdeep Singh
Third Year, Computer Engineering
Delhi Technological University
Ph: +91-9654115614
https://sites.google.com/site/adsingh1729/home
9 years, 10 months
Coding workflow and reading practices
by Jon Cruz
Hi Johan,
In the thread on GObject instantiation you happened to raise an interesting issue that probably warrants some good discussion.
You had mentioned that adding more to the headers "Saves some time wading through lengthy .cpp files only to find an almost empty function". Do you think you can expand a little on your use case where this type of practice is an issue? That is, can you give a quick description of some of the steps you would be going through when this problem pops up?
I know that different people have different learning and processing styles. (As an extreme example I've even worked with someone whose workflow was impacted by a change in Emacs that limited the number of open windows to only a couple hundred.) It would be good to be sure that we try to get things structured well for easier maintenance, etc.
Thanks.
9 years, 10 months
GObject object instantiation problem
by Sebastian Götte
Hi,
I'm currently having some problems allocating GObjects.
I just added a class called SPPoint [0]. When I try to instantiate an object of that type (whether through SPObject/sp_object_child_added or manually from GDB using g_object_new does not matter), g_object_new returns an GObject* that contains a zero class: {g_type_instance = {g_class = 0x0}, ref_count = 0, qdata = 0x0} (this is not good as it breaks everything else about G_OBJECT). I was able to track down the problem to g_type_create_instance returning that when passed the new SPPoint type:
(gdb) print sp_object_get_type()
$13 = 20593552
(gdb) print sp_point_get_type()
$14 = 20619024
(gdb) print *((GObject*)g_type_create_instance(sp_point_get_type()))
$20 = {g_type_instance = {g_class = 0x0}, ref_count = 0, qdata = 0x0}
(gdb) print *((GObject*)g_type_create_instance(sp_object_get_type()))
$21 = {g_type_instance = {g_class = 0x16ec560}, ref_count = 1, qdata = 0x0}
I'm currently building a glib with debugging symbols to further track down this problem.
If anybody here has an idea about what might be the cause of this problem, your suggestions will likely be tremendously useful since I'm already pondering over this for a few hours.
The code can be found at [1].
Thanks,
Sebastian
[0] https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/view/head:/src...
[1] https://code.launchpad.net/~h-e-6/inkscape/connector-wip
9 years, 10 months
Re: [Inkscape-devel] RDF nodes
by Markus Engel
I don't seem to get what you mean by "values" and "building blocks"? Is it
necessary to create a class just holding a key and a value? Wouldn't a
std::map suffice?
1)
The SPObject class exposes a method "connectModified" which you can use to
register a sigc::slot with the modification signal. This should work I hope.
Or look at "src/ui/dialog/document-metadata.cpp". Inside this file there's a
method called "on_repr_attr_changed":
/**
* Called when XML node attribute changed; updates dialog widgets.
*/
I don't know why this does not work currently.
2)
Sorry? When the xml tree is modified, the corresponding SPObject is
automatically informed, I don't think you have to do anything there
yourself. When you want to update the xml node after you made a change to an
SPObject, just call the modified SPObject's updateRepr method.
3)
Yes, I think so. The SPObject will stay, not as a struct but as a real class
;) . For the moment you'll have to get into creating a derived GObject
"class". There is an example in sp-skeleton.cpp. I'm just waiting for the
0.49 release to propose for merging, as I made some big changes to the code
base with probably some nasty bugs.
-----Ursprüngliche Nachricht-----
Von: inkscape-devel-request(a)lists.sourceforge.net
[mailto:inkscape-devel-request@lists.sourceforge.net]
Gesendet: Mittwoch, 31. Juli 2013 14:59
An: inkscape-devel(a)lists.sourceforge.net
Betreff: Inkscape-devel Digest, Vol 86, Issue 47
Send Inkscape-devel mailing list submissions to
inkscape-devel(a)lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
or, via email, send a message with subject or body 'help' to
inkscape-devel-request(a)lists.sourceforge.net
You can reach the person managing the list at
inkscape-devel-owner(a)lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Inkscape-devel digest..."
Today's Topics:
1. Re: [CAD] Next steps, a trivia question and discussion of the
semantics for what objects a connector should avoid (Sebastian G?tte)
2. Re: [Tracing] Report #6 (Vin?cius dos Santos Oliveira)
3. GObject object instantiation problem (Sebastian G?tte)
4. Re: GObject object instantiation problem (Jon Cruz)
5. Re: GObject object instantiation problem (Sebastian G?tte)
6. Re: GObject object instantiation problem (Tavmjong Bah)
7. Re: RDF nodes (Christoffer Holmstedt)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Jul 2013 21:20:42 +0200
From: Sebastian G?tte <jaseg@...2974...>
Subject: Re: [Inkscape-devel] [CAD] Next steps, a trivia question and
discussion of the semantics for what objects a connector should
avoid
To: inkscape-devel(a)lists.sourceforge.net
Message-ID: <51F8120A.6060506@...2974...>
Content-Type: text/plain; charset=ISO-8859-1
On 07/30/2013 01:57 AM, Michael Wybrow wrote:
> Hi Sebastian,
>
> A couple of quick thoughts:
> - You won't get the behaviour of avoiding specific obstacles with
different connectors using libavoid, since it routes connectors using a
single visibility graph built from the obstacles for the whole diagram.
Ok, I think that's fine. The only use case I can imagine is something like
PCB routing where you could want one visibility graph per layer.
> - I think it would be fine to mark objects as obstacles using something
other than a property.
> - The reason for not avoiding all obstacles by default is that libavoid
can be slow -- O(n^2 log n) -- especially if there are a lot of obstacles.
You don't want this slowness if you open a file with hundreds or thousands
of objects that libavoid tracks as objects by default. That was the reason
for the original decision to have the user explicit mark objects as
obstacles for routing.
Shouldn't this be in O(n log n)?
>> I'm now moving on to implement (somewhat minimalistic) "points" as
described in [0] so I can then head towards renovating
connector-context.cpp. My latest commit to launchpad breaks in an assertion
when drawing a connector since it needs these changes. The commit before
that should work, though.
>>
>> These "points" will be placed whenever one places a connector's end,
>> except if one places a connector's end on an existing "point". When
>> drawing a connector, all visible points will be rendered as knots.
>> This enables template-based diagram elements which are just are
>> groups that contain a shape and one or more points for the connector
>> to attach
>
> FWIW, newer versions of libavoid understand and track "connection pins".
These are points specified based on a position on shapes. They move if the
parent shape is moved and can be specified as the endpoints for connectors.
You might want to make of these.
Thanks.
This behavior can easily be implemented by putting a few SPPoints into a
group with some shape. The new connector code just creates these SPPoints as
needed, and handling of object centers/corners/nodes etc. should be done by
just snapping their locations to these points.
> It could be worth updating the version of libavoid in Inkscape to the
latest version found here:
> https://github.com/mjwybrow/adaptagrams
> The only real work there would be how you find and track attached objects
once using connection pins.
By moving to SPPoints this is actually pretty non-problematic since they
will just move with the groups containing them.
> I think there was a previous dev who started doing the connection pin work
in Inkscape but I'm not sure what happened to that. It doesn't seem to be
on the trunk.
>
>> I will remove any logic from connector-context responsible for handling
anything but two endpoints (if you want to draw a connector with multiple
"stops", just chain together multiple connectors) and remove the "snap
connector end point to connector's intersection with destination shape
outline"-logic since I do not think this is too useful.
>
> Do you mean the functionality that adjusts the endpoint of a connector to
stop at the intersection with the destination shape? If so, the reason for
this is that the arrowhead is drawn at the end of the connector and people
frequently want this to coincide with the edge of the shape.
I removed that because it would have been even more work porting and because
with the addition of SPPoints it is not really necessary anymore (I am not
totally against re-adding it, though).
Best regards, Sebastian
[1] http://dev.w3.org/SVG/modules/connector/SVGConnector.html
------------------------------
Message: 2
Date: Tue, 30 Jul 2013 18:02:00 -0300
From: Vin?cius dos Santos Oliveira <vini.ipsmaker@...400...>
Subject: Re: [Inkscape-devel] [Tracing] Report #6
To: Inkscape-dev <inkscape-devel(a)lists.sourceforge.net>
Message-ID: <1375218120.1439.6.camel@...16...>
Content-Type: text/plain; charset="utf-8"
Em Ter, 2013-07-30 ?s 04:23 -0300, Vin?cius dos Santos Oliveira
escreveu:
> I'll upload a short video later today showing the project summary.
Video uploaded: http://vimeo.com/71364024
--
Vin?cius dos Santos Oliveira
https://about.me/vinipsmaker
9 years, 10 months
