how to save last tool selection?
by Yale Zhang
Hello. Does anyone know how I can save and restore the last tool selection
on startup? You might ask why bother, but for my use case, I want Inkscape
to always start out with the eraser tool selected when I'm using the eraser
end of my pen (event source GDK_SOURCE_ERASER), to save me from having to
tap the erase tool with the eraser end of the pen.
Is there any reason why this isn't the default behavior? If saving the tool
selection isn't implemented, can someone show how to programatically change
the tool selection for the eraser to be the eraser?
Appreciate your help,
Yale
10 years, 1 month
mouse and tablet touch input lose focus after using Wacom pen
by Yale Zhang
Hello. I think I've found another bug in either Inkscape or GTK: I have a
Wacom Intuos 5 and whenever I use my pen, I can no longer use the mouse
wheel or 2 finger touch to zoom in and out.
It seems the problem is the window loses focus after using the pen.
Has anyone else noticed this problem or can propose where to trace to fix
the problem?
I'm using the latest trunk version and Windows 8.1, but this problem also
exists in 48.4.
Thanks for helping,
Yale
10 years, 1 month
Bug Counts on Website
by Martin Owens
Hey Devs,
I've got the django-cms-launchpad plugin working. The first integration
is pulling in bug counts for certain bug queries.
You can see an examples on this page:
http://staging.inkscape.org/en/develop/
What I've done is added a launchpad bug count widget when editing the
CMS. You can add them too. Just edit the page, edit the text widget and
add a bug count as you might an image. It links back to launchpad if you
click on it.
The widget has options for what tags, milestones and other items you may
want to search for. Not all fields are there yet, but I'm open to
requests from our bug managers about what's important to get an over
view of.
The low/medium/high counts are for colouring. Below low it's grey/white,
low>yellow>medium>orange>high>red and this can be used to give us a
quick visual on whatever we want to track.
Next feature for the django-cms-launchpad plugin is to format our
blueprints into a roadmap page. This won't be a widget, but a page and
targeted blueprints will be used to generate the list.
Martin,
10 years, 1 month
Version number
by Alex Valavanis
Hello All,
A while ago, there was a discussion about the numbering of the next
release. "0.49" doesn't exactly instill confidence in the completeness of
the application. On the other hand, "1.0" could be misleading with respect
to svg compliance. Other ideas were to use a date-based system "2013.10" or
something.
Any thoughts?
AV
10 years, 1 month
Only Three Blockers Left!
by Martin Owens
Hey Devs,
This is the bi-weekly report on our release-hope goal:
Blockers: 3
* High #1163449 Imported bitmap appear blurry when zoomed in
* Medium #953992 Imported pattern fill disappers while transforming
* Medium #1005892 Patterns applied to text objects are blurred
If you can fix one of these, please do. We can use all the help to
debug, locate the errors causing these regressions and fix them. These
blockers are high priority for our project goals.
We have 49 targeted bugs for the release:
http://tiny.cc/q3y34w
If you see something that you could easily fix, then this is a great way
to make the next inkscape version better.
I want to make a special mention of novalis' flowText fallback branch.
It's going through review right now but I want to give my biggest amazed
thanks to Novalis for tacking this difficult and long standing problem.
See the review here:
https://code.launchpad.net/~novalis/inkscape/fix-167335/+merge/190297
Keep up the good work everyone! Exciting to see so much work get done.
Best Regards, Martin Owens
10 years, 1 month
Re: [Inkscape-devel] W3C SVG test suite and trunk
by Guiu Rocafort
Hi. Sorry, my fault. Actually I thought i was sending the messages to
the mailing list, but by mistake i only sent them to martin and alex.
I send the messages again.
============ Email 1 ==================
2013/10/10 Alex Valavanis <valavanisalex@...400...>:
> Well, I guess the easiest thing would be to organise the svg input
> files for the rendering tests into two separate subfolders in
> known-pass/testcases and known-fail/testcases. We can then just tell
> the test runner to look in the appropriate folder:
>
> # cat run-svg-tests-good
> runtests.py --directory=known-pass
>
> # cat run-svg-tests-bad
> runtests.py --directory=known-fail
>
Ok, if I understood correctly, the idea here is to have known pass
tests, and known fail tests. All test with the respective pass/fail
test.
If a known pass test changes from the reference image then we can
assume we have a regression.
If a known fail test changes from the reference we might have solved
the problem, but since we can't automatically decide if it is already
solved, we would need to check manually and add it to the known pass
test if required.
That sounds to me like a good compromise between automation and some
manual work. The regressions would be detected automatically but the
improvements would need to be checked manually.
Thoughts about this ?
============ Email 2 ==================
2013/10/10 Martin Owens <doctormo@...400...>:
> On Thu, 2013-10-10 at 16:14 +0100, Alex Valavanis wrote:
>> two separate executable scripts
>
> Not yet. And while the python is pretty hairy (needs some code review)
> it should be possible to make it do what you want without too many
> issues.
>
> Guiu, Tav; what do you think? Would it be easy enough to modify and
> would you like to patch it or should I?
Yes, I think I could be able to modify the code to fit the current
code to be added to the testings. I sent a message trying to shade
some light on what needs to be done and trying to define the problem
exactly. If we're happy with what I propose, I can start making the
changes soon. There is some hairy code and rewriting some can do very
good in the readibility of the code.
Guiu
> Martin,
========= Message 3 ==============
Ok, sorry for sending that much messages, I just wanted to make a
little summary about the work that would be needed.
1. Get the SVG 1.1 Second edition test files and extract the text.
Jasper, in the link [1] you sent the files are from the Second edition
of the test suite or the first one ? Are they up to date ?
btw, I do actually think that removing the text is good, because if
there is a problem with the text rendering code, it would affect a lot
of tests. Removing the text from the tests we can isolate better what
we are testing with each file.
2. Then, we would need to manually separate the tests in pass/fail.
3. Implement the code as explained in the message I sent before. Then
add it to the tests in the current inkscape trunk to be executed every
time someone makes a commit.
4. Then a way to make this information public would need to be done.
But we can discuss this while the first points are made.
[1] https://svn.code.sf.net/p/inkscape/code/gsoc-testsuite/tester/testcases/s...
If we're happy with that and we agree that this is a good solution, I
can start working on this soon.
Cheers
Guiu Rocafort
I'm sorry about that
Guiu
2013/10/11 Martin Owens <doctormo@...400...>:
> On Fri, 2013-10-11 at 01:01 +0200, Guiu Rocafort wrote:
>> If we're happy with that and we agree that this is a good solution, I
>> can start working on this soon.
>
> You need to send this information to the devel mailing list. I recommend
> compiling your two emails into one and replying to all as it fits to
> have this sent to everyone.
>
> Martin,
>
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
10 years, 1 month
Weird bitfield declaration?
by Johan Engelen
Hi all,
I just found this in sp-root.h:
class SPRoot : public SPGroup {
...
bool viewBox_set : true;
I do not know what it means. Does it mean:
bool viewBox_set : 1;
If so, let's change it to a more recognizable format?
Cheers,
Johan
10 years, 1 month
C++ify workflow
by Markus Engel
Hi,
regardingr12593 „C++ify calling a few SPLPEItem functions, much more work thanexpected... slowly slowly…”:
I don’tknow what software you are using, with Eclipse my “optimized” workflow is asfollows:
1. Movefunction declaration in the header file into the class, remove the firstparameter
2. Go tothe function definition in the cpp-file, right click and select “Open CallHierarchy”
3. AddSPClass:: in front of the definition
4. Selectthe first parameter, press Shift+Alt+R and rename it to “this”
5. 6. Removethe first parameter, the function is c++ified
6. In theCall Hierarchy window go through the list and adjust the calls
7. Selectany occurrence of the function, again Shift+Alt+R and rename it
But I agreethat it’s a lot of boring, monotonous, repetitive work :) . It took me tons ofcoffee and some really long nightly sessions. Scripting this process isn’t thateasy either. At least now I’ve got some deeper understanding of how the partsfit together… and how not to write code. There were some really nice code partsin these files, e. g. marker.cpp, parsing the viewbox attribute by movingaround a char-pointer. This code appears 1:1 in sp-root.cpp ;) .
Regards,
Markus
10 years, 1 month
make -n blows up in trunk
by mathog
There is something wrong with the way make works in trunk. A regular
"make" completes, but doing
touch (a source file)
make -n
results in
...
Making all in po
make[2]: Entering directory `/usr/local/src/inkscape_trunk/po'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/local/src/inkscape_trunk/po'
make[2]: Entering directory `/usr/local/src/inkscape_trunk'
if perl ./po/check-markup ./po/*.po; [ $? = 1 ]; then \
echo "WARNING: Bad markup found in translations. Please
consider fixing the above problems." >&2; \
fi
if test ! -f config.h; then rm -f stamp-h1; else :; fi
if test ! -f config.h; then make stamp-h1; else :; fi
make[2]: Leaving directory `/usr/local/src/inkscape_trunk'
make[1]: Leaving directory `/usr/local/src/inkscape_trunk'
Just me or does that happen for other people too? I need make -n to
work so that I can see which compiler flags are being used on certain
files.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
10 years, 1 month
lib2geom bug in elliptical-arc.cpp
by Tavmjong Bah
Hi,
I just fixed a lib2geom bug in Inkscape's code (r12687). Don't know the
proper way to report it to the lib2geom team. Tangents for
counter-clockwise arcs were being calculated 180 degrees off causing
markers to be drawn wrong.
Tav
10 years, 1 month
