- Inkscape Devel - Inkscape Mailman

Automatic tests now in PPA
by Alex Valavanis 03 Aug '13

03 Aug '13

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=Search&…

1 0

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

03 Aug '13

>> 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

3 3

2 questions: Walk through all nodes and the two "different trees" SPObject/agnostic XML
by Christoffer Holmstedt 02 Aug '13

02 Aug '13

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

2 2

GObject removal branch
by Krzysztof Kosiński 02 Aug '13

02 Aug '13

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

5 13

[Recolor] Week #3: Moving onto Further Tasks
by Arshdeep Singh 02 Aug '13

02 Aug '13

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

2 5

Coding workflow and reading practices
by Jon Cruz 02 Aug '13

02 Aug '13

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.

1 0

GObject object instantiation problem
by Sebastian Götte 02 Aug '13

02 Aug '13

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/s… [1] https://code.launchpad.net/~h-e-6/inkscape/connector-wip

5 16

[Units] Completion of Phase One
by Matthew Petroff 01 Aug '13

01 Aug '13

I have now eliminated "unit-constants.h", removing the last of the duplicate general unit code. The one remaining section of somewhat duplicate unit code is the "SVGLength" class, but that is specific to the SVG specification, not general units. I plan on leaving it alone for now but may make it a child class of "Util::Unit" during phase two. I have submitted a merge proposal for my branch [1]. I plan on beginning phase two by hand-crafting SVG files with various types of unit configurations and work from there. http://www.mpetroff.net/archives/2013/08/01/completion-of-phase-one/ -Matthew [1] https://code.launchpad.net/~matthewpetroff/inkscape/gsoc-2013-unit-refactor…

2 1

Re: [Inkscape-devel] RDF nodes
by Markus Engel 01 Aug '13

01 Aug '13

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

2 1

Re: [Inkscape-devel] GObject removal branch
by Markus Engel 31 Jul '13

31 Jul '13

> Yeah, refactoring in a branch for too long is nuts. I agree with Josh that it's fine to merge into trunk if you think it's ready. For you, I think the sooner the better. Well, I think it is. Sometimes the factory issues a warning about rdf:RDF nodes, but as far as I know, Christoffer Holmstedt is currently working on license management and metadata handling. This has no effect on the functionality of the metadata dialogs, though. Regards, Markus Btw: Sorry if you received this message twice, I think I'll have to alter my mailing list subscription settings...

1 0

Re: [Inkscape-devel] Inkscape-devel Digest, Vol 86, Issue 49
by Markus Engel 31 Jul '13

31 Jul '13

> Yeah, refactoring in a branch for too long is nuts. I agree with Josh that it's fine to merge into trunk if you think it's ready. For you, I think the sooner the better. Well, I think it is. Sometimes the factory issues a warning about rdf:RDF nodes, but as far as I know, Christoffer Holmstedt is currently working on license management and metadata handling. This has no effect on the functionality of the metadata dialogs, though. Regards, Markus

1 0

Re: [Inkscape-devel] GObject object instantiation problem
by Markus Engel 31 Jul '13

31 Jul '13

> 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 . Regards, Markus

1 0

Re: [Inkscape-devel] RDF nodes
by Markus Engel 31 Jul '13

31 Jul '13

Hi, I generated the documentation for the object tree and picked out the relevant parts for you: https://dl.dropboxusercontent.com/u/37427492/sp-object.pdf https://dl.dropboxusercontent.com/u/37427492/sp-metadata1.pdf https://dl.dropboxusercontent.com/u/37427492/sp-metadata2.pdf Note that this is not how it is currently implemented in trunk, but in my own branch instead. This shouldn't matter for understanding, though, I just converted the tree to "real" c++ classes. SPObject is the base class for all tree nodes. As you can see in the first pdf, every svg element has got one counterpart of the right class in the object tree. Whenever a change is made to an xml node, it informs the tree node belonging to him by calling for example onUpdate(). The tree node then updates its internal state. Whenever possible, one should work on the tree nodes and leave the xml nodes alone. You'll find lots of information on this in the inkscape wiki, e. g. "Changes in the XML tree are automatically propagated to the object tree via observers, but not the other way around-a function called updateRepr() must be explicitly called." As the rdf information is not a drawable object (-> SPItem subclasses), it should probably derive directly from SPObject. Maybe you could then add it as a member to SPMetadata. I'm not quite sure how to handle that best either. We should wait for some more opinions. or just try it out :) . Regards, Markus > Hi Markus > I started work on Inkscape earlier this year (April/May). During the summer > I work with Commons Machinery [1] to improve metadata handling and the GUI > for metadata and license information. In this prototype I'm working with > the idea that multiple metadata tags are allowed and therefore multiple rdf > tags (though only one per metadata tag). With my limited experience with > Inkscape codebase and the object tree I'm not sure how to best refactor RDF > to fit in. > > In an earlier discussion with Peter Liljenberg [2] he said that a refactor > of RDF should be done to be more general and easy to work with. I'm not > sure about the specifics about this but I will look into it later on in > August hopefully. > > You seem to have a lot more experience with the Inkscape codebase than I > have so it would been fun to discuss any changes that is done here in this > area with you. The goal now for me is to complete the prototype with as > simple code as possible and then during the summer/fall (when time permits) > refactor so it can be merged into Inkscape trunk. > > Concerning GSOC merge before 0.49, I don't know. > > [1] http://commonsmachinery.se/ > [2] https://launchpad.net/~peter-liljenberg <https://launchpad.net/%7Epeter-liljenberg> > > -- > Christoffer Holmstedt >

2 2

[Tracing] Report #6
by Vinícius dos Santos Oliveira 30 Jul '13

30 Jul '13

All algorithms proposed on the previous blog posts are implemented now: * http://vinipsmaker.wordpress.com/2013/07/22/splines-extraction-on-kopf-lisc… * http://vinipsmaker.wordpress.com/2013/07/21/splines-extraction-on-kopf-lisc… I'm attaching some samples. The samples are visually the same of the report #3, but if you edit the files with Inkscape or examine the XML, you notice that all polygons are being grouped. I'll upload a short video later today showing the project summary. Now I can play with B-Splines generation and optimization. Better yet, the smoothness computing is already done (and it worked in my tests also). -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

1 1

[CAD] Status report
by Sebastian Götte 30 Jul '13

30 Jul '13

Hi, the last few days I dug myself into connector-context.cpp, making that thing compatible with the routing changes I did last week. So far, this has proven quite a task and I am not done yet. A snapshot of the current changes (not yet compiling since I'm midways in it) can be found on launchpad[0]. The main missing parts (apart from actually connecting everything back together after ripping it apart) are fitting g_signal and sigc++ together and getting all the rainbow-colored curves right. I'll follow up if I have any questions. Best regards, Sebastian [0] https://bazaar.launchpad.net/~h-e-6/inkscape/connector-wip/files

2 3

Helping with translations in staging.inkscape.org
by Guiu Rocafort 28 Jul '13

28 Jul '13

Hi ! I would like to help with the translations of the staging website. Do I need a Django account for helping with that here ? ( http://staging.inkscape.org/admin/ ) Can someone create an account for me ? Thank you Guiu Rocafort -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

3 4

[Units] Removal of SPUnit and SPMetric
by Matthew Petroff 26 Jul '13

26 Jul '13

After spending a few days reading GTK+/gtkmm documentation, I was able to make good progress and have completely eliminated SPUnit and SPMetric from the code base. I'm a few weeks behind schedule but hope to finish the refactor before the end of the month. http://www.mpetroff.net/archives/2013/07/22/removal-of-spunit-and-spmetric/ -Matthew

3 2

[Recolor] Fetching number of objects selected
by Arshdeep Singh 26 Jul '13

26 Jul '13

Hi, I need to get the number of selected objects on the canvas. I was using the following code: GSList const *items = selection->itemList(); int selObj = g_slist_length (const_cast<GSList*>(items)); the const_cast was required because: guint <http://www.gtk.org/api/2.6/glib/glib-Basic-Types.html#guint> g_slist_length <http://www.gtk.org/api/2.6/glib/glib-Singly-Linked-Lists.html#g-slist-length> (GSList <http://www.gtk.org/api/2.6/glib/glib-Singly-Linked-Lists.html#GSList> *list); If I comment out the g_slist_length command, there is no runtime error. And Inkscape run's perfect. In this scenario, what can I do to get the length of the GSList ? -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

2 1

[Inkscape- Devel][Recolor] Default Arguments Compiling Error
by Arshdeep Singh 26 Jul '13

26 Jul '13

Hi, I have been trying to write a function with a default argument. The function: void recolor_wheel_nodes_init(GtkWidget *widget , int obj_list_size = RECOLOR_MAX_OBJECTS ) { ..... } This gives the following error: expected ';', ',' or ')' before '=' token Aren't default arguments allowed in GTK ? I bet I've seen them at a few places in the codebase before. -- Arshdeep Singh Third Year, Computer Engineering Delhi Technological University Ph: +91-9654115614 https://sites.google.com/site/adsingh1729/home

3 3

Handling missing point attribute in input SVG
by Tomasz Boczkowski 26 Jul '13

26 Jul '13

Hello, Since it is my first post here, I would like to introduce myself. I'm CS student interested in FLOSS software and C++ development. I would like to contribute to Inkscape to raise my programming skills and do something good this year. I've begun by solving bug #1202753. For polygon elements in input file, that have empty or no "points" attribute SPShape::curve field is NULL. According to comment in sp-polygon.cpp:125 this should not be the case. When points="", sp_polygon_set does not initialize SPShape::curve. Comment in sp-polygon.cpp:169 refers to W3C note: http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing. How should this situation be handled in document tree? Regards, Tomasz Boczkowski

2 1

RDF nodes
by Markus Engel 26 Jul '13

26 Jul '13

Hi there, I have not been in for quite a while, but now I've got some time to spend on inkscape again! :) I just looked at this RDF thing and I'm wondering whether it should rather derive from SPObject than being so "separated"? I mean, one document has one metadata node and that should have exactly one rdf node in it, shouldn't it? Currently, RDF nodes do not have any counterpart in the object tree... Btw, do you plan on merging the gsoc results before 0.49? Regards, Markus

2 1

Making a Windows binary
by unknown＠example.com 24 Jul '13

24 Jul '13

Dear Inkscape developers, I am working on a variant of Inkscape (well, "fork" but with no hostile intent towards such a great project) and while it runs and compiles just file on my Linux box, I haven't managed to make a Windows binary. I tried the native build on Win32 route but `pygobject` is needed (`pygobject.h not found`) for this particular variant. Basically, I think if I just add `pygobject` to the `devlibs`, everything will work out fine but I have no idea how to do this and I was hoping to get a quick answer from one of you since you already know your way around the codebase. If its something easy, feel free to skip the rest of this message which contains details of what I tried. I don't know the first thing about adding the needed paths for cross-compiling with `i586-mingw32msvc-g++` so I failed pretty quickly there (setting environment variables such as CXX worked fine but `make` then failed to find `libpng`). So I tried building on a (shared) Windows machine using MinGW. `buildtool.cpp` compiled fine (with a warning) and running it started the build process with no apparent problem (it didn't recognize the -j flag though) until it didn't find `pygobject.h`, which is obviously missing. I then installed Python and pygobject (using the PyGTK all in one bundle) but that didn't help (pygobject.h is missing), probably because those are runtime libraries with no header files. The entire goal of making such a build is so that I can get some testers. So I'm also happy to hear other options. (I haven't tried a Mac build yet since I don't have access to such a machine to test the output binary.) Thanks for your time (both in making Inkscape what it is and maybe answering my question).

1 0

Re: [Inkscape-devel] Inkscape-web what the next set of pages?
by Jared Meidal 23 Jul '13

23 Jul '13

I think I'm hearing it be helpful if blueprints were created of the staging webpages, to use as scratchpads and landing sites for arrangement of content goals. I have made blueprints before, but if this would be helpful I'm happy to work on it. I'm asking for clarification because I don't want to clutter up launchpad with posts that are not toward the vision that's desired. --Jared

2 1

Inkscape-web what the next set of pages?
by Leo Jackson 23 Jul '13

23 Jul '13

Hello Inkscape-web developers, Do we have a place to list the next items to be done; I can see a lot of pages we can move. Are we putting them on the Wiki as a Roadmap or Google Doc or something. Regards, Leo Jackson

3 7

Re: [Inkscape-devel] Inkscape Website: Tutorials
by Jared Meidal 23 Jul '13

23 Jul '13

I can add a list of additional tutorials to the Tutorials webpage [http://staging.inkscape.org/en/learn/tutorials/] if third-party tutorials belong there, such as these: http://www.chrishilbig.com/a-crash-course-in-inkscape/ https://inkscapetutorials.wordpress.com/ http://www.techdrivein.com/2011/08/10-good-inkscape-tutorials-for-vector.ht… http://creativenerds.co.uk/tutorials/inkscape-tutorials/ I see the Videos section many "third-party" tutorials are being gathered there. These ones above are primarily not videos. Thanks for the feedback. --Jared

4 7