I create a proposal.
Citando Alexandre Prokoudine <alexandre.prokoudine@...400...>:
> IIRC, Jimmac was going to work on it.
.ValessioBrito - Comunicação e Tecnologia
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).
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.
- 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.
- 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.
Inkscape. Draw Freely.
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,
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? :)
Inkscape. Draw Freely.
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,
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:
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).
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.
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.
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."