- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Multipage support as a GSoC project?
by gespertino＠...400... 31 Mar '11

31 Mar '11

I'd add hyphenation to the Text items. And the ability to specify in points instead of pixels at least the size of the type.

3 4

Doxygen cleanup
by Jon Cruz 30 Mar '11

30 Mar '11

First of all, is anyone using our doxygen docs, or does anyone care about the format? Our current usage is a bit inefficient, so I've been thinking of cleaning it up a bit. First on the hit list are those annoying "@brief" instances. Or config file has this: > # If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen > # will interpret the first line (until the first dot) of a JavaDoc-style > # comment as the brief description. If set to NO, the JavaDoc > # comments will behave just like regular Qt-style comments > # (thus requiring an explicit @brief command for a brief description.) > > JAVADOC_AUTOBRIEF = YES So that means instead of : /** * @brief XML - prefs observer bridge * * This is an XML node observer that watches for changes in the XML document storing the preferences. * It is used to implement preference observers. */ We can do: /** * XML - prefs observer bridge. * * This is an XML node observer that watches for changes in the XML document storing the preferences. * It is used to implement preference observers. */ The key point is to just have a single period so that the first sentence *is* the brief description. No need for additional work or @ tags.

6 12

proposal to enhance the python extensions
by Mark Schafer 29 Mar '11

29 Mar '11

Hi everyone, I've been lurking on this list and making extensions for Inkscape in python. (I'm also keen on the dbus scripting but I use windows so no good for me right now...) I have had difficulty understanding what some of the extensions do and in writing my own I have discovered the notebook tab. I want to suggest using the notebook tab at the top of each extension to help document how they work. Here is a screenshot of a suggested UI from my Lasercut box extension. http://www.flickr.com/photos/33807726@...2603.../5569339514/ Extra tabs could break up the info for clarity and show data like author,url, etc So I propose: - supply a template for people writing extensions to use as a starter - and some docs/tutorials on making extensions in python - modify the existing extensions included in Inkscape to follow this guideline - maybe fix broken extensions if there are any (I haven't tried every one) But I don't want to do something the dev team thinks is a waste of time, and I am unsure of the translation issues with such an approach. Any thoughts ? Mark...

6 7

GSoC 2011 - Mentors
by Josh Andler 29 Mar '11

29 Mar '11

Hey all, It appears that Melange's invitation system is not currently working (I can't seem to invite via link_id or email addresses). If you're interested in mentoring, please visit http://socghop.appspot.com/gsoc/org/google/gsoc2011/inkscape and apply to be a mentor. Thanks for your time! Cheers, Josh

1 0

Merging the Cairo branch
by Josh Andler 29 Mar '11

29 Mar '11

Hey, So, I really think that we should entertain the idea of merging the cairo branch into trunk. The plan has been for us to not release 0.49 until it is ready, so the couple outstanding bugs in cairo shouldn't be a huge deterrent. We could also set up a PPA to produce the trunk builds of cairo & pixman so that fixed libs are easily installable in the meantime (at least for people using debian-based systems). I was talking to John Cliff and he put forth a very good point which is that we really need to get as much testing as possible on it prior to a release. Before it gets asked, yes Jon, color management is broken in it atm. The likelihood of it getting fixed in a branch as opposed to trunk is next to non-existent though... So, would people be okay with a little breakage of existing functionality to get more testing of a cairofied Inkscape? bulia, I included you in the to line here to help gauge the acceptability of this proposal. Cheers, Josh

6 10

GSoC project ideas
by Krzysztof Kosiński 29 Mar '11

29 Mar '11

Hello I'm not 100% sure yet whether I'll be able to participate in GSoC 2011, but here are my ideas. They can be used by other potential participants. 1. Selections A lot of functions in Inkscape operate on the current selection. This includes things like moving objects to another layer, creating a bitmap copy, etc. This leads to a lot of unnecessary code duplication when some other function needs to reuse selection-specific logic in a way that is not tied to the UI. It also precludes any useful implementation of scripting (e.g. one that does not need to modify the user's selection every time a script is run). In order to rectify this, we should create an object that represents an arbitrary collection of SVG elements. It would work like the selection we have now, but would not be tied to any UI elements - it would just represent an ordered set of elements that can be passed to functions. 2. Fix flowtext Use svg:switch to fix flowtext. Make svg:switch transparent to the SP tree - e.g. a switch should not have its own SP element, the active part of the switch should be transparently included into the SP tree. This can be accomplished by allowing every object to have more than one representation. 3. Make XML private Discussed before. Was the object of a previous year project, but the main effect of that was mass renaming and moving of code into classes rather than any meaningful improvement in encapsulation. The main thing we need is an ability to create SP nodes. Right now we create XML nodes and rely on SP tree callbacks to construct the SP node for us. 4. Typed XML tree The XML tree stores strings, which is rather wasteful and leads to a lot of boilerplate in SP object implementations. We have enough knowledge about the document at the XML level to know the type of each attribute and CSS property based on its name. Storing parsed values would save space, particularly for embedded images, at the cost of slightly more expensive saving. GVariant could be used. 5. GTK3 compatibility This would involve removal of deprecated code, so that Inkscape compiles with both GTK2 and GTK3. 6. 2geom improvements Move and rewrite code 2geom to the point where it can take over the job of livarot, libavoid, etc. Document the new code and make sure it fits nicely with existing code. The scope of the project could be limited to implementing Boolean operations on paths. 7. Rendering speed improvements Further work on the Cairo branch in several small sub-projects: a) Instead of re-rendering the same pixels every time a new tile of a filter is rendered, cache them until the rendering is done. The implementation could involve allocating screen-size bitmaps for each layer of a filtered object and filling them with data in small increments. b) Render editing controls to a separate image that is composited on top of the drawing, so that what a path outline is highlighted, there is no need to re-render the object under it. c) Render each layer of the drawing to a separate image; alternatively, render 3 images: everything below current layer, current layer and everything above. This would allow the user to give us some hints. Regards, Krzysztof

3 3

Greetings
by Eric Kuzmenko 28 Mar '11

28 Mar '11

Hello there fellow inkscape-devel mailing list subscribers, I'm Eric Kuzmenko, a programmer want-to-be. Almost none of you have met me, I just want to establish a position in your community, hopeful I can obtain someone's friendship here. Anyway, I just wanted to state that I am going to attempt to apply for gsoc sometime late next week. I'm currently trying to get a grasp of the gtkmm wrapper in order to press that knowledge to fixing some bugs and getting those two patches in before April 8, though there's a great chance I won't be able to due to the amount I need to learn. Even if I fail to get that far this soon I will continue attempting to help patch up the code during the summer, whether it with gsoc or not, hopefully I can be of some help. If you've read this far then thank you. =)

2 1

Fedora, Open Clip Art Library, and Inkscape
by Tavmjong Bah 27 Mar '11

27 Mar '11

Hi, I just came across this. I don't know anything about how "Import from Open Clip Art Library" works but at least one person thinks it will be broken in Fedora 16 as Fedora is planning on removing gnome-vfs2. http://lists.fedoraproject.org/pipermail/devel/2011-March/149571.html Tav

3 2

GTK3
by Inti Alonso 27 Mar '11

27 Mar '11

Hi, Im a regular Inkscape user, and with all the noise about the coming of the new GTK3, I want to know if Inkscape is already working in the GTK3 port, or when will that happen. I guess GTK3 can bring some improves to or beloved Inkscape.

3 6

[GSoC] SVG + javascript
by Fernando Lucchesi 26 Mar '11

26 Mar '11

Hi inkscape-devels, I've been lurking for a while, but didn't introduce myself yet. I'm Fernando Lucchesi, and I am at my third year studying Computer Engineering at Unicamp, Brazil. I am a member of the CS/CE Students' Union of Unicamp(CACo), where my role is roughly to do "graphical stuff", almost always using inkscape. That includes posters[1], t-shirts, etc. Since I rely on Inkscape so much, it was about time I got to contribute with some code. For that, I am willing to participate on this year's GSoC. (I realize that only using Inkscape doesn't mean I can hack it, but it means I want to see it get even better) Last year, I was playing with SVG/JSONP trying to make a widget to show the cafeteria menu[2]. While doing that, I realized that the javascript support could use some love. Searching a little, I've found this blueprint: https://blueprints.launchpad.net/inkscape/+spec/scripting-ui So I would like to work at something along those lines. I've chatted a little at the Inkscape Brazil mailing list, and already got some pointers. These are the ideas so far: -Enhance "Object properties > interactivity" by replacing the text boxes with combo boxes containing every javascript function/method available. To do that, it would be necessary to parse both external and embedded scripts. -Open embedded scripts on an external editor (perhaps blocking the svg edition while doing that). It would be a way to follow the unix philosophy of using the best tool for every job (inkscape - graphics; vim/emacs/some ide - code). That script list would be located at "document properties > scripting", under the external scripts. As Aurium pointed out, the name of the tmp file would have to be meaningful not to scare the user, so perhaps using the script id could be an option. Also, the way to create new scripts would be at the same interface, you'd just need to define the script name/id at its creation. -At the same place there could be a list of svg elements using script events. -We could encourage people to use .js files for scripts, since it is good practice to separate the structure from the action (like with html/js). The problem, however, is that by doing that there would be 2+ files instead of a single svg, making the distribution more difficult. As a way to solve that, inkscape could have an option to automatically embed external scripts, so there would be only one file. There should be some config regarding scripts on another server (so you don't save a static version of JSONP data, for example). Then, there would be the opposite direction, taking the embedded scripts out to the corresponding .js files. This wouldn't be restricted to scripts previously inserted by inkscape, but all embedded scripts. The name of each file to be created would be asked, except for those that came from a .js in the first place, since its name would be saved on the tag. Another option is to use the id defined by the other interface instead of asking. So, how could this fit into a GSoC project? (I'm yet to send the 2 patches, but I've already pulled the code from bazaar, successfully compiled it and am having a look at the bugs at launchpad). [1]: http://www.students.ic.unicamp.br/~ra091187/etc/reuniao.png [2]: http://www.students.ic.unicamp.br/~ra091187/teste/bandeco.svg -- Fernando Lucchesi Bastos Jurema UNICAMP - Engenharia de Computação 09 CACo - Centro Acadêmico da Computação Coordenador de Marketing e Produtos - gestão 2010/2011

1 0