- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] display/sodipodi-ctrl.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

On 5-8-2013 23:13, Krzysztof Kosiński wrote: > 2013/8/5 Johan Engelen <jbc.engelen@...2592...>: >> 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. > No, the increment is necesary, because this line is copying an image > row by row. Otherwise it would fill p with copies of the first pixel > in the row. > > The only thing to do here is to perhaps move the declaration of px > inside the loop. Ah, lol, getting late :-) Missed the for loop completely, doh! Thanks for paying attention better than me. Cheers, Johan

1 0

extension/internal/cairo-render-context.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

Hi all, in CairoRenderContext::renderGlyphtext, the variable 'size' is never used. Somewhere halfway, there is some error checking it seems, that sets size explicitly to some hardcoded default value of 12.0. But again this is never used in the method. Is it a bug? Or should it be removed/commented out? Thanks, Johan

1 0

[CAD] Next steps, a trivia question and discussion of the semantics for what objects a connector should avoid
by Sebastian Götte 05 Aug '13

05 Aug '13

Hi, I'm moving on refactoring the connectors code. I just changed the toolbar a little bit so every connector type has its own button. During refactoring, two questions arised: 1. What does "Ege" as in "EgeAdjustmentAction" mean? 2. What semantics do we want concerning which objects are to be avoided by a connector? A little elaboration on the second question: Currently, Inkscape uses libavoid to route object-avoiding connectors. All object which should be avoided by the router are added an "inkscape:connector-avoid" attribute. This does not, e.g., allow an object to be avoided by certain connectors and ignored by others. I can currently see three obvious solutions to that problem: * Avoid objects based on group/layer membership. E.g. avoid any objects on the same top-level layer but ignore others. * Avoid objects based on a "tag". This is not unlike the current approach, but I would really use a class instead of an own attribute for this to be easily interoperable with other implementations of this, especially a potential javascript router as discussed with Doug Schepers from w3c, who is currently working on a SVG connectors spec. Personally, I favor the second solution since I think it is less hacky and more flexible. I think it would be a sane choice to have connectors avoid objects by default and to explicitely mark objects to be ignored while routing. If you wanted a connector ignoring any objects you could just use the non-libavoid routing types I am just adding. * Any combination of the above If you have any thoughts on this, please share them with me ;) 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. 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. Best regards, Sebastian [0] http://dev.w3.org/SVG/modules/connector/SVGConnector.html#PointElement

4 9

dom/cssreader.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

Hi all, For those who know about dom/cssreader.cpp, is this code correct? In CssReader::getPage(int p0): int p = p0; ..... XMLCh ch = get(p); if (p != '{') { error("@page requires '{' before declarations"); } Shouldn't that be if (ch != '{') ? It happens a number of times in that function and looks like a bug to me. If it is indeed correct the way it is now, please add comments to those locations, because it is quite confusing. Thanks, Johan

1 0

display/sodipodi-ctrl.cpp
by Johan Engelen 05 Aug '13

05 Aug '13

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

1 0

[CAD] Status
by Sebastian Götte 05 Aug '13

05 Aug '13

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/

3 2

Re: [Inkscape-devel] GObject removal branch
by Markus Engel 04 Aug '13

04 Aug '13

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

1 0

floating dialog transient behavior
by Johan Engelen 04 Aug '13

04 Aug '13

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

2 2

memset on SPStyle
by Johan Engelen 04 Aug '13

04 Aug '13

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

2 3

[Tracing] Library integration/API design
by Vinícius dos Santos Oliveira 03 Aug '13

03 Aug '13

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

3 4