- Inkscape Devel - Inkscape Mailman

Future development
by Josh Andler 13 Feb '12

13 Feb '12

Hey All, So I think we need to discuss a few things related to development. 1) Regarding the irc dev meeting it appears that two weeks from today on 02/25 at 0800 UTC is the time that worked the best for the most people. Everyone, please put that on your calendar. 2) We're close to cutting 0.48.3, given the state of 0.49, we will also pursue 0.48.4. 3) We need to think seriously about GTK3 at some point. We may want to create a GTK3 branch sooner rather than later to begin that work. It would be good to get other people's thoughts on this. Do we want to take on A) 3 active development branches and B) 2 active refactoring branches. I will note that I don't believe there is a full set of GTK3 libs available for win32 yet and have no idea about the status on OSX. Cheers, Josh P.S. Tavmjong, I cc-ed you explicitly because you didn't put the time we ended up with as available. Any chance it can be made to work?

9 15

Inkscape 0.48.3?
by Alex Valavanis 12 Feb '12

12 Feb '12

Hi All, Any thoughts about when we're going to release Inkscape 0.48.3? Coming at this from an Ubuntu maintenance perspective, the next LTS release (12.04 - "Precise Pangolin") will hit feature freeze on Feb 16, so it would be great to update the binary-package in the Ubuntu-main repository before that date. Large numbers of Ubuntu desktop users could potentially end up sticking with it for a couple of years, so I think it makes sense to squash as many bugs as possible! Does anyone else agree with releasing 0.48.3 in the very near future? Is there any reason to hold back? If we're going to do this, we'd need to release a source tarball by ~9 Feb. We've already committed a fair number of bug fixes in 0.48.3[1], so it would probably already be useful to users in its current form. However, perhaps a two-week bug-squashing session would be nice before we go ahead. Best wishes, AV [1] https://launchpad.net/inkscape/+milestone/0.48.3

7 18

inkscape at graphicall
by Alexandre Prokoudine 12 Feb '12

12 Feb '12

Hello gang, Given that we are now parted from modevia, how about unloading builds to graphicall which mostly hosts Blender builds? It already has an Inkscape section that looks rather lonely. Alexandre Prokoudine http://libregraphicsworld.org

6 10

How to fix Aligning stroked and strokeless items & bounding box issues?
by Эльдар Файзуллин 10 Feb '12

10 Feb '12

Here: https://bugs.launchpad.net/inkscape/+bug/473608 It came from 0.47

3 2

Inkscape and XML whitespace handling
by Andi McClure 10 Feb '12

10 Feb '12

I am trying to create a patch to Inkscape and it isn't working very well, I was hoping I could ask for some help. I have been using Inkscape for creating resources for a video game I'm writing. As part of this I often attach custom attributes to XML nodes in the "XML Editor" window. When I do this, Inkscape gives me a nice big multiline editor window to enter my attribute text. Sometimes, I find myself needing to enter many lines of text or code into one of my custom attributes; when I do this, Inkscape handles newlines in a way that strikes me as incorrect and makes it very hard for me to get work done. Inkscape will allow me to enter, set and save multi-line attributes; however then later when I try to open the file, all the newlines will be erased, replaced with spaces. Although I understand newlines are rarely relevant in normal SVG, it seems very wrong to me that Inkscape allows me to enter content, save a file, and then reopen the file and it has been silently altered. I have been trying to fix this behavior on my own. What I found is that if you put a newline into an attribute and then save, Inkscape will actually write the newline raw into the file, like-- <example:example attribute="one two three four" /> When the file is opened the next time, Inkscape silently turns all newlines into spaces. The convert-newline-to-space behavior is apparently not only correct, but required for a conformant XML parser: http://www.w3.org/TR/2008/REC-xml-20081126/#AVNormalize So my conclusion is that if Inkscape is doing something wrong here (which I think it is), the mistake is that it should not be writing newlines raw into the file, rather it should be saving the appropriate XML entity (
 or 
). I have a local branch (patch attached) where I have attempted to implement this change. I can't get it to work. I found four separate places in the source code where strings are escaped into XML entities for storage; I added a '\n' -> 
 rule to each, and taught xmlreader.cpp to convert 
 back into '\n'. The reader change seems to have worked (I can manually write a &#xA into a file, and when loaded in Inkscape it becomes a newline) however, when I write a newline into an attribute and then set and save, Inkscape is still writing raw newlines instead of my escaped attribute. While making this change, I noticed two things that seem problematic: - XML entity escaping is done in at least four separate places in the code! - The XML reader in dom/xmlreader.cpp appears to only recognize a small number of hand-entered entities. At the moment there is no provision for loading any kind of &# style entity, which if I'm not missing something means Inkscape could choke on valid SVG XML produced by a different program. Should either of these two things be fixed? And would anyone know why my attempts to add '\n' to the escaper are having no effect? When you enter text into the attribute-value box in the XML editor, what path does it take in being entity-escaped (i.e. " becomes " and so on)? One more question-- other than this one problem the XML editor in Inkscape is quite nice, are there any examples of standalone programs for Mac or Linux that allow you to edit general XML in this manner? Thanks. - mcc http://runhello.com/

2 1

keyboard uneable with inkscape
by Rosa Alonso Garcia 09 Feb '12

09 Feb '12

Only I can to work with mouse. version inkscape 0.46.0 Keyboard uneable. MACOS Tiger. thanks. Rosa M. Alonso Garcia Il.lustradora gràfica http://rosailustradora.com http://rosailustradora.blogspot.com

1 0

libcroco
by Alex Valavanis 08 Feb '12

08 Feb '12

Hi All, Just wondering what the status of our libcroco fork is at the moment. Upstream development has restarted, and version 0.64 was released yesterday. It appears that Abhishek Sharma pushed some of our changes upstream, but then reverted them. Can anyone shed some light on this? Thanks, Alex

2 2

inkscape on a G5
by Drechsel Wolf 05 Feb '12

05 Feb '12

Hi everyboy, yesterday I succeeded it repairin an imac G5 1,8GHz. On this brand new machine I'm making an entierly new inkscape experience. Did some professional work - wow, it rocks. Compared to my slightly outdated G4 - what a difference… Therefore - what is said too seldomly: THANKS FOR MAKING INKSCAPE !! - I love it! BTW.: Can someone give me a quick hint: How can I find out on which (probabely locked) layer an object resides? - Couldnt google an anser for that. Greetings, Wolf

3 5

Inkscape tiling interface redesign proposal
by Valerie 05 Feb '12

05 Feb '12

Ah well, I have no idea if the wiki image upload issue will be fixed, so I just made everything into an image and uploaded it somewhere else: http://postimage.org/image/7f9ms5kw3/ As you can see, central concepts include: 1. Transformations separated into groups that people other than tile mathematicians understand 2. And moved to a dedicated dialogue. Basically: - One-time filters -> floating boxes - Properties that may need future editing -> side-dialogues By the way, radial transformations to use polar coordinates. 3. Top level interface to address most common use cases, while more advanced options (clutter) are moved to an extra button that you can access. 4. Guides can be edited on canvas... 5. ...and locked or unlocked to objects, so you can create half a vase, stick a symmetry on it, then move the whole thing around as though it were one object. 6. Stacking symmetries or tilings as you would LPEs I'm probably missing a lot of things, but it doesn't hurt to make a few proposals to see what people's thoughts are. :) So what do the rest of you think? Is this a direction you think can lead somewhere, or do you think the interface should be taken in a completely different direction?

5 12

support multiple extension locations
by Tim Cuthbertson 05 Feb '12

05 Feb '12

I was looking into how one might provide inkscape extensions using 0install[1], which basically amounts to adding extensions _without_ touching any well-known paths, typically using environment variables. I've done the same thing for gnome-shell, by essentially adding each extension's location to $XDG_DATA_DIRS. So for example to run gnome-shell with the shellshape extension[2], $XDG_DATA_DIRS might contain the following dir: /home/tim/.cache/0install.net/implementations/sha256=2437376cd245ee4f09b0738e1cc7392a04750a9cec4b0875bf71606703d9ee01/xdg which contains a `gnome-shell` directory with the files you would normally put in /usr/share/gnome-shell if you were installing them system-wide. I wondered if this would work for inkscape as well, but after having a look at the source, it doesn't seem likely. Based on the `profile_path` function in inkscape.cpp: - inkscape seems to assume that there will be at most one folder for each of (user, system) level preferences - it assumes preferences and extensions will all live in the same location. These both go against the XDG spec[3], which recommends that config and data live in different locations and should be able to be looked up in a cascading fashion (i.e supporting multiple paths in $XDG_DATA_DIRS). These restrictions also make it very difficult to use 0install to distribute extensions since that would require: - readonly `extensions` directories - all 0install implementation directories must be read-only as they can be shared between users (among other reasons) - cascading lookup of extensions in _all_ paths in $XDG_DATA_DIRS - adding or removing plugins must be possible by affecting what is in XDG_DATA_DIRS, rather than modifying folders in the filesystem. So, I guess my questions are: - am I wrong about my conclusions here? I've looked at the source, but may have missed something. - is there any interest in extending the extension loading mechanism to support loading extensions across all $XDG_DATA_DIRS? Presumably this would be implemented for _all_ data types (gradients, icons, etc) as well as just extensions. Cheers, - Tim. [1]: http://0install.net/ [2]: http://gfxmonk.net/dist/0install/shellshape.xml [3]: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

3 3