Tablet stopped work in Dev builds
by microUgly
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-tp20171213p201712...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
13 years, 10 months
PerspectiveObject / Envelope Effect
by G33K
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
13 years, 11 months
(no subject)
by worms invasion
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
13 years, 11 months
Re: [Inkscape-devel] Snapping toolbar
by Diederik van Lierop
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
13 years, 11 months
more gradients
by Alexandre Prokoudine
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
13 years, 11 months
Re: [Inkscape-devel] Inkscape 0.47 - was Re: GSoC 2009 - Project handling in the repository
by Guillermo Espertino
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
13 years, 11 months
GSoC 2009 - Project handling in the repository
by Joshua A. Andler
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
13 years, 11 months
