January 2010 - Inkscape Devel

node tool - color of helperpath
by unknown＠example.com 17 Jan '10

17 Jan '10

Hi Krzysztof, I've been fiddling a bit with the new node tool. It's nice! But, the color of the helperpath of a path with an LPE applied is confusing. The original path used to be colored red, and the LPE-path-parameter green (or to another color if set by the LPE itself). Could you change the green back to red for the original path? Thanks, Johan

1 0

bazaar - how to make a patch
by unknown＠example.com 17 Jan '10

17 Jan '10

Hi all, How do I make a patch from a checkout? Annoyed, Johan

2 4

Re: [Inkscape-devel] Spray tool icon
by Valessio S Brito 17 Jan '10

17 Jan '10

I create a proposal. see attach. Citando Alexandre Prokoudine <alexandre.prokoudine@...400...>: > IIRC, Jimmac was going to work on it. > > Alexandre -- .ValessioBrito - Comunicação e Tecnologia Blog: http://valessiobrito.info Chat: valessio(a)[jabber.org,msn.com,gmail.com] Cel.: 71 8256-2396 Atenção: Este e-mail pode conter anexos no formato ODF (Open Document Format)/ABNT (extensões odt, ods, odp, odb, odg). Antes de pedir os anexos em outro formato, você pode instalar gratuita e livremente o BrOffice (http://www.broffice.org) ou o seguinte Plugin para Microsoft Office (http://www.sun.com/software/star/odf_plugin/get.jsp). Também arquivos vetoriais no formato SVG use (http://www.InkscapeBrasil.org).

5 6

UI issues...
by bulia byak 17 Jan '10

17 Jan '10

My previous query was somehow sidetracked, so here it is again: - Can anyone give rationale for "Print colors preview" being in Display modes? If not I will remove it from there, as I explained it looks very out of place next to Outline and No filters. Also: - We also have "Color-managed view" in the same menu. Duplicate? If they are genuinely different, please name them to better reflect this difference, and place both in an appropriate submenu of View. Otherwise, merge them. And: - We again have two Input Devices commands. Can we finally decide one way or the other? Does the new one fully work? If so delete the old one, otherwise hide the new until it is ready. Thanks! -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

5 11

diameter on a Mac
by Wolf Drechsel 17 Jan '10

17 Jan '10

Hello friends, sorry, I know this is not an issue for the list, but … (-; Can somebody give me a quick hint how to type the ø diameter sign on inkscape Mac OS X ? Alt-o will open a menu, and a Mac does not have AltGr… Thanks and greetings, Wolf

4 7

Spray tool icon
by bulia byak 17 Jan '10

17 Jan '10

The new icon by Krzysztof is a step in the right direction, but it's still somehow out of place on the toolbar. Hey artists, don't you want to get famous by drawing one of the always-visible Inkscape tool icons? :) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

resize text boxes
by Wolf Drechsel 16 Jan '10

16 Jan '10

Hello friends, how can I resize text boxes without resizing the font ? - What I want is that the font size remains stable and the number of lines increases when I make a text box narrower. Thanks and greetings, Wolf

2 1

Node tool is ready
by Krzysztof Kosiński 15 Jan '10

15 Jan '10

Hello all Today I have implemented snapping of nodes, so the new node tool should be ready to go into trunk. As a reminder, here is the status table: http://wiki.inkscape.org/wiki/index.php/GSoC2009_Node_Tool_Rewrite There are still some minor issues with snapping: 1. Nodes do not snap to unselected segments of selected paths. 2. Nodes do not snap to selected shapes. They will be fixed once I refactor the event context / tool hierarchy, which I plan to do before this year's GSoC. Now I have a few remarks / questions about the behavior: 1. There is an RFE: https://bugs.launchpad.net/inkscape/+bug/321150 The proposed is like the new node tool's join action, but with a distance threshold. Implementing this should be easy, but I don't know how to present it in the UI. Ideas, anyone? 2. Releasing the mouse button causes the point to immediately snap, even if the snap delay has not expired. For me, this unexpected and very annoying: I have to turn off snapping to make a non-snapped movement. If this feature was removed, I could comfortably make both snapped and non-snapped movements with snapping enabled. Currently I disabled snapping on mouse button release. 3. When a point snaps to a path, it should remain snapped to it until the pointer wanders outside the snap distance. This would allow me to adjust the point's position on a path it snapped to, without waiting for the snap delay to expire every time. Same behavior for snapping to nodes, corenrs, etc. (the point remains snapped until I move the mouse pointer out of the snapping range). What do you think? 4. The method to switch to the transform handles to rotation mode is very non-obvious. Currently it is Shift+R. To be consistent with the selector, the method to switch to rotation mode should be to click on a selected node, but this might become annoying quickly - the old behavior is to select only the clicked node in this case. I think the second behavior is acceptable if it only works when transform handles are shown, and the handles can be toggled using a button on the controls bar (preferably the first one). Regards, Krzysztof.

7 40

We are good to go!
by Joshua A. Andler 15 Jan '10

15 Jan '10

Hey all, I made the first commit on LP after our trunk branch was established and it went smoothly. So, everyone, feel free to go to town! As a side thought, since 0.48 will be maintained for a bit while 0.49 is under development. What do people think about our use of LP and how we use Fix Released rather than Fix Committed... are people game to perhaps try using Fix Committed (and target them for 0.48 when doing so) for this cycle? If we properly use committed and mark where it will be available, we can then just script it to change to released when it really is (I think it will be nicer for users). Just a thought. Cheers, Josh

9 19

NEW: remove boost::optional warnings
by Krzysztof Kosiński 14 Jan '10

14 Jan '10

Hello I put in some extra code in configure.ac to turn off strict aliasing warnings when boost::optional emits a lot of them. It tries to compile a short snippet using boost::optional with -Werror=strict-aliasing, and if it fails, it adds -Wno-strict-aliasing to CXXFLAGS. It might be a bit unsafe, because we won't see aliasing warnings from things other than boost::optional, but on the other hand the legitimate warnings that can highlight real problems won't be crowded out by those spurious warnings we can't fix Relevant mail from the Boost mailing list. http://lists.boost.org/Archives/boost/2009/05/151577.php And the relevant quote. "Precisely... a char* is explcitely allowed to alias any object, so, for Boost.Optional at least, the warning is clearly spurious." Regards, Krzysztof

2 4