- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Improved boundingbox calculation
by Guillermo Espertino 11 Apr '10

11 Apr '10

Please, don't forget bug #365458. I guess it's somewhat related and it's extremely annoying. 0.47 was released with that important regression, it would be great if it's reverted in 0.48.

2 1

How to fix Wacom stylus in Inkscape 0.47-3 on Windows
by Jon Cruz 11 Apr '10

11 Apr '10

Just wondering if our Win32 guys have seen this about issues with Tablets on 0.47. http://www.anthonywyatt.com/blog/2009/11/29/how-to-fix-wacom-stylus-in-inks… Do we have all this covered now, or not?

2 1

Improved boundingbox calculation
by unknown＠example.com 10 Apr '10

10 Apr '10

Hi all, I just committed an improved bbox calculation when SPItem::RENDERING_BBOX precision is requested. Now it correctly includes stroke endcaps. This fixes an important bug: when creating a pattern from selected objects, the bbox calculation was not accurate enough for paths with butt caps. This meant it was not easy to make a pattern of a plus to create a hatch fill pattern. (the plusses would not connect with each other) Now this works as easy as it should. I have also increased the precision of the bbox calculation for fitting the canvas to the selection and for turning the selection into a marker. Note that the improved RENDERING_BBOX calculation takes more time than before (in fact, RENDERING_BBOX used to be the same as APPROXIMATE_BBOX). Ciao, Johan

2 2

bzr repo format
by Kees Cook 10 Apr '10

10 Apr '10

Hi, I'd like to upgrade[1] the inkscape bzr repo to the latest format version. Is anyone using bzr that is too old to handle the 2a format? -Kees [1] https://code.edge.launchpad.net/~inkscape.dev/inkscape/trunk/+upgrade -- Kees Cook @outflux.net

3 2

GSoC 2010, pen tool and layers dialog
by Matthew Todd 09 Apr '10

09 Apr '10

Hello, My name is Matthew A. Todd. I am a second year computer science student at UCSD interested in working on Inkscape as part of Google Summer of Code. During my use of Inkscape previously, I had wanted a couple of changes/feature additions. I would like the chance to add these features, with some help, as my project in GSoC. I'm posting here for feedback regarding my ideas. I don't have enough experience to know how long it would take to implement them. I don't even know if others besides myself would even find such functionality useful. First idea (pen tool): I primarily use the pen tool, and would like to add the following to it: When drawing a curve, often times I place a node then decide I want to move the node's position. In Adobe Illustrator, this is accomplished by simply pressing a key (the space key.) I would like to add this ability to Inkscape. Currently, this is already possible through the use of the arrow keys. But allowing the user to move the node with the mouse would increase ease of use because the user wouldn't have to take his or her hand off the mouse. Also it would allow him or her to move the node more quickly. And he or she could still use the arrow keys if desired. Because the arrow keys method already exists, adding the use of the mouse is by no means of high importance. But several times I have desired such functionality. Second idea (layers dialog): I find the layers dialog to be a little cumbersome. Its not possible to simply move layers up and down by dragging them. Instead an user has to click a button or press a key combination. I think adding this small feature will increase ease of use because then the user doesn't have to click multiple times if there are many layers. He or she could simply just drag the layer to the desired location. The layer dialog doesn't show what is in a layer. So currently, the only option is to hide all other layers, which still isn't a great solution. Adding the ability to inspect items in a layer and move them in z-order or perhaps even move them to other layers, would make layers work better. I'm thinking of something would look like a tree view. Again, I came over from Adobe Illustrator, so my idea of what it would like is similar to how Illustrator's layer dialog, but it need not be. Thanks, Matthew A. Todd

4 3

Re: [Inkscape-devel] Intel Aqua packaging
by ~suv 09 Apr '10

09 Apr '10

On 8/4/10 13:40, Lloyd Sargent wrote: > Okay, I went back and looked at the build info and I've found two problems: > > #1. > <...> > The following build commands failed: > ScriptExec: > ProcessPCH /var/folders/D+/D+KS42xe2RWRN++1YwAjD++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/ScriptExec_Prefix-fufpslfnljyhqverjsxrfdvyqeus/ScriptExec_Prefix.pch.gch ScriptExec_Prefix.pch normal ppc c com.apple.compilers.gcc.4_2 > ProcessPCH /var/folders/D+/D+KS42xe2RWRN++1YwAjD++++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/ScriptExec_Prefix-ewyzzpalxmpnnsapxxvoyqkdnuir/ScriptExec_Prefix.pch.gch ScriptExec_Prefix.pch normal i386 c com.apple.compilers.gcc.4_2 > (2 failures) See my earlier answer to Stuart: On 22/3/10 14:00, ~suv wrote: > Yes, the lack of MacOSX10.4u.sdk is obviously significant for the > available xcodeproject of the application launcher. Please be aware that > the release version 0.47 was not built on Snow Leopard, nor are the > current development snapshots built on Snow Leopard. I.e. you are trying > to do something new that seems to require part of the packaging modules > to be modified and updated to run on OS X 10.6 Snow Leopard. > > I recommend to file a bug report, detailing the SL related errors you > see when trying to package the application. Please include all relevant > information about your OS and Xcode version. I'm not familiar with Xcode projects and don't know what changes are needed to compile 'ScriptExec' on Snow Leopard. Earlier in this thread it was mentioned to use gcc 4.0 instead of gcc 4.2 when employing the MacOSX10.4u.sdk on SL, but I don't know which changes you'd have to make to which files to change the compiler for the Xcode project only (you don't want to downgrade the compiler when building MacPorts or Inkscape itself). Looking at your error messages I see two issues to be addressed: 1) carbon vs cocoa (i.e. has anyone tried to create a new application launcher - ScriptExec - based on a current version of Platypus that might build with the 10.5 or 10.6 SDK?) 2) Universal build for PPC/i386 as target? (i.e. do we need 'ScriptExec' to be built Universal on Snow Leopard, and if so, does it need to support PPC - considering that SL doesn't run on PPC arch - or should the (platypus) launcher application be built either as Universal i386/x86_64 or as x86_64 only on Snow Leopard?). > #2 > > cp: /opt/local/etc/pango/pangox.aliases: No such file or directory > > Which makes sense as I have no pangox.aliases... what package would > this be from. I've built and installed pango, so that's not the problem... Has been answered in this thread already: the file is installed by pango when compiled with support for the X font backend. AFAICT the file is not needed when using Inkscape with GTK+/Quartz and both the packaging scripts and the application launcher script put inside the application package will have to be adapted to not look for this file when building/launching Inkscape without X11: On 22/3/10 14:00, ~suv wrote: > The GTK+/Quartz (so-called "Aqua") version will also require changes to > both the build scripts and the launcher scripts - but this should be > handled in a separate bug report, similar to the one Wolf filed for > removing the code launching X11 on Tiger. ~suv

3 4

Hello Inkscape Developers
by Peter Boström 08 Apr '10

08 Apr '10

Hello! I thought I'd finally send out a word or two and introduce myself. My name is Peter, I'm a second-year computer-science student at the Royal Institute of Technology here in Sweden. I've been programming casually for a few years before school, but most things I've done have either been simple or been abandoned. Though as a last-year project for high school, I made a simple fast Guitar-Hero clone in C. I'm also currently working on a game with a friend, which is slowly coming together. I'm making a proposal with Google Summer of Code to create a new New-From-Template dialog. I think Inkscape has a good interface, and it's one that I'd definitely want to help improve. Without previous experience with the code base, it's also a project that I find feasible to finish. A template menu, I think, is a good thing, so it's a part that I'd want to keep. I just think it needs to become structured into categories as well. So if you just need a static template for a CD, you can go to New.. -> Covers -> CD. In case this proposal gets accepted, I'd want to regularly provide something for feedback, either from this list or a mentor, wherever suitable. I think the interface is important, so this needs to be something that everyone would find easy to use. Also, I'm very interested any ideas you may have. (: Best to mention: I submitted a patch that resolves the following wishlist ticket: https://bugs.launchpad.net/inkscape/+bug/43730 This patch reports export results to the main window status bar. To have it report properly, I had to change sp_export_png_file's return type, as suggested, to an enum. It now returns EXPORT_OK, for a successful export, EXPORT_ERROR=0 for an error, and EXPORT_ABORTED for a canceled overwrite. I think it's a good change, because it makes this dialog more verbose. I hope you agree. Existing code checks for a false value, if(! sp_export_png_file...), which still works, same as before. I'd be happy to answer any and all questions you might have! Best regards - Peter Boström

1 0

Re: [Inkscape-devel] Intel Aqua packaging
by ~suv 08 Apr '10

08 Apr '10

On 8/4/10 05:50, Lloyd Sargent wrote: > 1. Macports installed at /opt/local > > 2. DYLD_LIBRARY_PATH was uncommented. > > With the above I get the same error as the OP (worse I had to make sure > the 10.4 SDK was installed). > > So something else is going South. Any suggestions? I don't know what error you are referring to - it might help if you attach the crash log / console messages (but I haven't built the +quartz version myself nor am I using Snow Leopard - which I assume you do since you mention the 10.4 SDK optional install?) ~suv

1 0

Mac OS X: osx-dmg.sh - osascript: dmg_set_style.scpt
by Wolf Drechsel 08 Apr '10

08 Apr '10

Hello everybody, I tried to dmg inkscape 047 X11 - but ended up with an image, which contains a link to /Applications and a folder called "Contents" - which seems not to be a .app bundle. When running the osx-dmg.sh, I get the message: osascript: dmg_set_style.scpt: No such file or directory In fact, the dmg_set_style.scpt cannot be found on my machine, it looks as if it were contained by earlier source packages and dropped recently. Could somebody be so kind and mail me the script - or - in the case - guide me to another solution of that problem. Yours, Wolf

6 21

Document versioning (was: Coordinate system fix)
by Krzysztof Kosiński 08 Apr '10

08 Apr '10

W dniu 6 kwietnia 2010 18:31 użytkownik bulia byak <buliabyak@...400...> napisał: > 2010/4/6 Krzysztof Kosiński <tweenk.pl@...400...>: >> W dniu 6 kwietnia 2010 15:33 użytkownik bulia byak >> <buliabyak@...400...> napisał: >>> This sounds inevitable, but rather hairy. Why have both >>> inkscape:version and inkscape:document-version? Can you get what you >>> need with inkscape:version only? >> >> 1. Document version changes must be atomic, because the upgrade is >> conducted only one time for each type of defect. This means >> inkscape:document-version (or inkscape:document-format) can change >> several times between two releases. > > But why can't we just fix ALL the defects we find between 0.47 and > 0.48 and have just two states of upgrade for <=0.47 and for >=0.48? The upgrade procedure must run exactly once for any document. This means that if we introduce a change in the interpretation of XML between revision FOO and FOO+1, then FOO+1 must perform the upgrade on documents saved in FOO and earlier, but it must also be smart enough not to upgrade documents saved with FOO+1. That's true regardless of how many defects are fixed in each version or how many document formats there are. This means the version number must be accurate down to a single revision, which is a bad idea for reasons I've already mentioned. If we have only the bare version number (e.g. 0.47 or 0.48), then anything saved in FOO+1 or later cannot be opened until we make a stable release. It would be possible to have the document format version number equal to the Bazaar revision in which it was first introduced. However, this would complicate working on the backwards compatibility fixes in branches. I think a simple number increasing from 1 would be the best way to go. This is hairy, possibly tedious to implement, etc., but at the same it's the long-term solution. Regards, Krzysztof

6 18