March 2009 - Inkscape Devel - Inkscape Mailman

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

Tablet stopped work in Dev builds
by microUgly 28 Apr '09

28 Apr '09

I just downloaded the Oct 24 Windows build and found that my tablet isn't working properly with it. I can move the cursor with tablet pen, but when I press on the tablet nothing draws. I tried toggling the "Use pressure" button. My tablet still works fine in 0.46 and was working in an earlier build I was using last night (I don't think it was more than a week or two old). Let me know if you require a bug logged for this. -- View this message in context: http://www.nabble.com/Tablet-stopped-work-in-Dev-builds-tp20171213p20171213… Sent from the Inkscape - Dev mailing list archive at Nabble.com.

6 17

PerspectiveObject / Envelope Effect
by G33K 15 Apr '09

15 Apr '09

Hello, I am very interested in the PerspectiveObject feature that is mentioned in the roadmap for milestone 15 / Inkscape 0.49. Has the implementation already started? Couldn't find any information. Also, the link to the example on the wiki seems to be broken. Does anyone know what it was showing? Perhaps I might get my hands on a developer machine in a few weeks, so I might be able to help out. In the meantime, I'd like to try and fix the Python implemented envelope effect. It looks like it's only using the corners of the envelope for the perspective, but doesn't take any curved sides into account. Can someone tell me in which directory I can find the source code for that one? Many thanks! Gerrit -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html

5 15

(no subject)
by worms invasion 10 Apr '09

10 Apr '09

Hello I noticed that in the "Save as" dialog, when you save a new file, the fields order when you do TAB is: File Name Type Save Cancel Title So you more likely will hit "Save" before you get a chance to fill in "Title". I remember a discussion about this on IRC, and the goal of adding the Title field was that it shouldn't "get in the way" of the user, or something, even though the "Title" field is part of the SVG specification (or something like that) So I'm wondering... would it make a big difference to have the order: File Name Type Title Save Cancel For people using the mouse to go from field to field, it won't make a lot of difference (I think), but for those like me who use TAB in that dialog, it would (3 TAB instead of 5, but 4 TAB instead of 3 for save) Also, it's a "Save as" dialog, so if you change the File name or the Type, there are chances that you would also change Title maybe, but the current order makes it more likely that you hit "Save" first. The same comment applies to the "Save a copy..." dialog. Anyway, that's only a question - I'm curious about why the current order is as it is, that is all :-) What do you people think? Regards

3 2

Re: [Inkscape-devel] Snapping toolbar
by Diederik van Lierop 05 Apr '09

05 Apr '09

Op Vr, 16 januari, 2009 01:39, schreef Rock Star: > The difference between creating and editing can be somehow seen from the > video [1]. That video indeed explains everything! A few months ago I introduced a snapping delay, which makes snapping in Inkscape much more responsive in complex documents. That snapping delay is what you noticed when editing objects, but it apparently it doesn't work when creating objects. I will fix that. If however you prefer the old behavior without any delay, then just go the preferences -> snapping and set the delay to zero. > Now I see the problem with guides and grid and toggles. However, since I > come more from a CAD world, I'm used of snapping to whatever is visible. > Hence, if there are 2 grids turned on, I would expect to snap to both. > This > would than mean 2 more toggles. If you see grid/guides it snaps, otherwise > not. Maybe it isn't a problem after all to add an additional toggle in series. When creating a grid, the per-grid snapping is turned on by default. So if a user is not aware of this then he won't notice, and if he turns it off then... well, that's his/here responsibility ;-). So we would end up with these options in series: 1) the global snapping toggle -> EVERY USER MUST KNOW ABOUT THIS** 2) the GLOBAL grid snapping toggle -> CLEARLY RECOGNIZABLE ON THE TOOLBAR 3) the PER-GRID snapping toggle -> ON BY DEFAULT 4) snap bounding box corners toggle or the snap nodes toggle -> EVERY USER MUST KNOW ABOUT THIS TOO** **) ... but only if they care about snapping obviously. > Anyway, thanks for the answer and additional explanation. You're welcome. Thanks for your feedback! Diederik

5 15

chebyshev.cpp missing
by bulia byak 05 Apr '09

05 Apr '09

during recent 2geom update, this file was not added, preventing compilation -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

more gradients
by Alexandre Prokoudine 05 Apr '09

05 Apr '09

Hi, Here is an interesting patch in the tracker: https://bugs.launchpad.net/bugs/346681 "This is a .diff file containing code that allows Inkscape to generate spiral gradients, as well as conical or angular gradients as a degenerate case. It allows the user to create and edit these gradients with the gradient context (tool) and the Fill and Stroke dialog in the same manner as a Radial gradient. It also includes an (ugly) icon for use in the Fill and Stroke dialog and Gradient toolbar." How come no has one commented for 5 days now? :) Alexandre

16 61

Re: [Inkscape-devel] Inkscape 0.47 - was Re: GSoC 2009 - Project handling in the repository
by Guillermo Espertino 04 Apr '09

04 Apr '09

There's a pretty large amount of 0.46 bugs being reported again and again in launchpad, and most of them are fixed in SVN. I guess that stabilizing the SVN and fixing important bugs and regressions to release Inkscape 0.47 as soon as possible would have a significant impact (positive) in the reduction of duplicated bugs. I personally don't care if some filters, lpes or features don't make it. I'd prefer a stable 0.47 with the bugfixes and the enhancements that may be considered "stable". Even with its regressions and some high importance bugs, the SVN version is pretty stable and it has loads of improvements (snapping, pdf output, eraser, spiro, etc.) that would make 0.47 attractive enough, from the user pov. And that would help to close lots of fixed bugs for good. So +1 for the idea of starting the freezing and regressions hunt. Gez

2 1

GSoC 2009 - Project handling in the repository
by Joshua A. Andler 04 Apr '09

04 Apr '09

Hey All, Due to concerns and issues voiced in the past, it seems like we should talk about how GSoC projects should be handled in our repository. A big concern is the impact on Trunk and if we want to release 0.47 with minimal pain this year. Given that I'm the hold-over release warden for 0.47, and that I have also taken on future release related duties from bryce... I'd like to see things work as smoothly as possible. What are some thoughts on what to do? Should we stick to the way we did it in the past and potentially introduce much more breakage in the near future? Branches on an as-needed basis? Perhaps just a GSoC2009 branch for all students work to be committed to? I could see the latter being beneficial to ease testing all their work with no harm to trunk the process. Additionally, it's a great way to learn about our "don't break trunk" rule... the students will be forced to commit responsibly as breaking it would hinder all other students too (which I would hope they'd be vocal yet diplomatic in handling). Any and all thoughts are welcome. Cheers, Josh

10 18

Inkscape DVCS - was: Re: GSoC 2009 - Project handling in the repository
by Jeff Kowalczyk 04 Apr '09

04 Apr '09

The GSoC 2009 might present a good opportunity for inkscape to move to a DVCS. Students, mentors and testers would benefit from enhanced branch, merge and branch tracking capabilities at github, launchpad, bitbucket, et al. Jeff

7 14