- Inkscape Devel - Inkscape Mailman

Inkscape 0.48 Chill (the winter is heavy everywhere!)
by Joshua A. Andler 18 Mar '10

18 Mar '10

Hey all, This is where 0.48 as a "release" begins! This email will be a little redundant for developers, but will let users know what the current plan is. The next stage (Frost) kicks into gear at the beginning of March in case you were wondering. For right now: *New feature development will focus on wrapping up. *We will identify "make check" issues (we need to make sure things are "friendly" for packaging). *We will run an About Screen contest on DeviantART (which I will announce within the next 24 hours and post all info to both lists). *Ensure that the Release Notes are at First Draft stage. This is primarily a developer task, however, if you are a user and follow development closely and have something to contribute in this area which we may have overlooked, such as fixed bugs, changes in functionality, etc. please contribute. *Update tutorials and other docs (we could use volunteers). Not joking, if you are an Inkscape user and have the misconception that the only way you can contribute is by code, you are missing out on one of the most important things for our users... documentation. If you have time to spare and some tips for others that you're willing to share, please let us know. --- boring developer junk --- I do want to request from developers... most "big" new stuff be committed by March 1st if possible (or shortly thereafter). JonCruz: The swatch previews for "auto" swatches are starting to worry me given that they have not been working for quite a while now (since 0.47 dev cycle). The same goes for the method of editing color (gradient editor rather than F&S dialog). If you will not have time to address these before Freeze, please expect that I will request the feature is disabled again for this release at that time... I will also request that in 0.49 that you not re-enable it until you are looking to actively work on it. Krzysztof: The new Node Tool is fantastic. I know you're actively working on it, but I do just want to make sure that you will be able to set aside a few hours here and there for bugfixing as there are still a number of bugs and features missing from previous releases. Arcadie/Michael: The Connector Tool really is not consistent with the behavior of other tools. If it is not likely to be sorted out by Freeze, I will request that at least the tool controls button for "add connection point" be disabled, as it is not user friendly at this point. Please know that I am not targeting people or criticizing their work. This is a schedule issue and our date of release was horribly far behind schedule for the past couple releases. We will just be sticking to release schedules much more strictly than we have previously, and if features aren't "bug-free"/complete enough to release on time... there's always next release! :) Besides, we're going to be in the trenches w/ 0.49 for a bit by what has been discussed so far. Cheers, Josh

4 3

Event processing issue
by Diederik van Lierop 17 Mar '10

17 Mar '10

Hi all, Someone surely must see an easy fix for this annoying bug I ran into the other day. ~suv reported that scrolling the canvas using the scroll wheel is prohibited when the pointer is hovering above the snap indicator (see the last paragraph of this comment: https://bugs.launchpad.net/inkscape/+bug/522335/comments/8). This becomes very reproducible and annoying when using a dense grid, together the pre-snap indicator, in for example the rectangle context. Through debugging I learned that the scroll events reach sp_canvas_scroll() (just as they should), and from which they should be dispatched via emit_event() (in sp-canvas.cpp). But this only works if the canvas->current_item has been set, but in this situation the current-item is null. Now my question is: what should the current-item be set to in this case, and how do I control this? Thanks, Diederik PS: This is a stack trace of how things should work, in this case there was no grid and therefore no snap-indicator was drawn: Thread [1] (Suspended: Breakpoint hit.) 31 sp_canvas_scroll_to() /home/diedenrezi/InkscapeBZR/inkscape/src/display/sp-canvas.cpp:2179 0x00000000006161fa 30 SPDesktop::scroll_world() /home/diedenrezi/InkscapeBZR/inkscape/src/desktop.cpp:1110 0x0000000000a744f6 29 sp_event_context_private_root_handler() /home/diedenrezi/InkscapeBZR/inkscape/src/event-context.cpp:707 0x000000000046279f 28 sp_rect_context_root_handler() /home/diedenrezi/InkscapeBZR/inkscape/src/rect-context.cpp:448 0x0000000000af5f6d 27 sp_event_context_virtual_root_handler() /home/diedenrezi/InkscapeBZR/inkscape/src/event-context.cpp:941 0x0000000000463222 26 sp_event_context_root_handler() /home/diedenrezi/InkscapeBZR/inkscape/src/event-context.cpp:937 0x00000000004631ed 25 sp_desktop_root_handler() /home/diedenrezi/InkscapeBZR/inkscape/src/desktop-events.cpp:67 0x0000000000a7a682 24 sp_marshal_BOOLEAN__POINTER() /home/diedenrezi/InkscapeBZR/inkscape/src/helper/sp-marshal.cpp:352 0x00000000006cf763 23 g_closure_invoke() 0x0000003e9180ba8e 22 <symbol is not available> 0x0000003e91820ec3 21 g_signal_emit_valist() 0x0000003e918220ec 20 gtk_signal_emit() 0x00000031668e3bd2 19 emit_event() /home/diedenrezi/InkscapeBZR/inkscape/src/display/sp-canvas.cpp:1348 0x0000000000613f57 18 sp_canvas_scroll() /home/diedenrezi/InkscapeBZR/inkscape/src/display/sp-canvas.cpp:1581 0x0000000000614928 17 <symbol is not available> 0x0000003166753a33 16 g_closure_invoke() 0x0000003e9180ba8e 15 <symbol is not available> 0x0000003e91820b8d 14 g_signal_emit_valist() 0x0000003e918220ec 13 g_signal_emit() 0x0000003e918227a3 12 <symbol is not available> 0x000000316687620f 11 gtk_propagate_event() 0x000000316674a794 10 gtk_main_do_event() 0x000000316674b8d3 9 snooper() /home/diedenrezi/InkscapeBZR/inkscape/src/main.cpp:896 0x000000000044d569 8 <symbol is not available> 0x0000003166e5fe9c 7 g_main_context_dispatch() 0x0000003e9143920e 6 <symbol is not available> 0x0000003e9143cbf8 5 g_main_loop_run() 0x0000003e9143d045 4 gtk_main() 0x000000316674be07 3 sp_main_gui() /home/diedenrezi/InkscapeBZR/inkscape/src/main.cpp:962 0x000000000044db86 2 Inkscape::NSApplication::Application::run() /home/diedenrezi/InkscapeBZR/inkscape/src/application/application.cpp:114 0x00000000005acada 1 main() /home/diedenrezi/InkscapeBZR/inkscape/src/main.cpp:698 0x000000000044cf9e

2 3

Re: [Inkscape-devel] Hello!
by Dmitry 17 Mar '10

17 Mar '10

M> Unfortunately it's not a simple answer, and I haven't had a lot of time M> yet since getting back from London. The most useful place for MT is in M> software rendering. There are not many other places in the codebase M> which would really benefit from it. M> -mental Hello MenTaLguY! I would like to know why multi-threading haven't been realized in Inkscape for so long time, many users wrote that they would like to have full power of theit multi-core processors. I'm starting doing this work and I want to know what are the difficulties, is it real to complete in 2.5 months working 8 hours per day? And tell me please as more as you can about this problem in Inkscape. -- Best regards, Dmitry mailto:Dmitry.Jurasov@...400...

6 9

Rendering test server unstable
by Niko Kiirala 17 Mar '10

17 Mar '10

Automated rendering tests for Inkscape have been run for a couple months now. The results are visible at http://auriga.mine.nu/inkscape/ (opening that page can take a while, as it is javascript-heavy) Unfortunately, the server I've used for running the tests and for hosting that website has become unstable, shutting down with no warning or visible reason. It is likely that the tests won't be run every day and the result page may be unavailable every now and then. -- Niko Kiirala niko@...1267...

1 0

Move "Task" to the View menu
by Krzysztof Kosiński 16 Mar '10

16 Mar '10

Hello I think the "Task" combo box should not be in the main toolbar, but in the View menu under the name "UI Layout" or "UI Mode", analogically to the "Display Mode" submenu. This fixes three problems at once: 1. The main toolbar is no longer super-wide when it's vertical. 2. The combo box no longer jumps around the UI. 3. The unclear word "Task" is replaced with something more explicit. Regards, Krzysztof

5 9

Work on NFT dialog for GSOC 2010
by Albin Manoël 16 Mar '10

16 Mar '10

Hi developpers About GSoC, I have read that this is a full-time job between may and july. But in this time, my studies aren't finished (because of the french school system). That's why, I realized that I can't participate to GSoC. Anyway, this not a problem for me. My own goal is to contribute to Inkscape and not to earn money with Google. So I'm ready to begin the specs with Alexandre. And then, when the specs will be finished, I will probably ask you for a "mentor" in order to help me programming. So, I am going to improve the specs when I have time ;-) see you ! Albin Manoël 2010/3/8 Joshua A. Andler <scislac@...400...> On Mon, 2010-03-08 at 10:52 +0300, Alexandre Prokoudine wrote: > > On 3/5/10, Albin Manoël wrote: > > > > > If the spec aren't finished, we can begin now to improve them. Are you > agree > > > ? > > > > I'll see what I can do. I'm quite lacking spare time at the moment and > > trying to do too many things at once already. > > Albin, I will see if we can get other volunteers to help flesh out the > spec a little more... however, if no one is able, it may be a last > minute "here are the basics of what you need to accomplish" situation. > Then again, this is assuming that we are accepted as a mentoring > organization and that slots permitted, your proposal is selected. > > > > About mentoring, I would enjoy that you become my mentor. And for > programing > > > questions, I think that developers can help me :-) > > > > I'm not sure that it is the right way. I'd first hear from the > > organization's admin. > > That is not the right way. We need to have Albin paired up with a > developer as the mentor. That's not to say that Alexandre can not give > input and feedback, as I've done that with a majority of our SoC > students in the past. Right now we've only had one possible developer > agree to be a mentor this year, so if that's all we have to offer (and > are accepted by Google), competition with proposals will be fierce. > > Cheers, > Josh > >

2 1

0.48 About Screen Contest is a go!
by Joshua A. Andler 15 Mar '10

15 Mar '10

Hey All, We do have recent builds for Windows & OSX now, so, it's now time to begin the contest. Find out more at: http://inkscapers.deviantart.com/blog/30919607/ Cheers, Josh

1 0

Tests and making code testable
by Jon Cruz 14 Mar '10

14 Mar '10

Hi, you mentioned this so I think it really warrants a good thread and discussion to itself: > I have no idea what you are trying to say. The test in question tests > the Preferences object. It is not possible to replace it with a stub > because then the test becomes meaningless. Aside from a stub, for some cases, a test mode or other things are very very useful. It's good that you recognize where something itself is being tested that the thing should not be changed. However, things around it can and should be changed. If we have code that is a monolithic mess, then it will be hard to deal with and maintain. It will also be harder to understand intentions and desired use of the API, etc. I think you hand encountered all of these when you did your cleanup pass on the preferences. Given the state of things when you started, the current code is pretty nice. However we do have an opportunity to improve it even more and get things quite solid and maintainable. What it sounds like to me is that we have some good opportunity for a better understanding of Test Driven Development (TDD). http://en.wikipedia.org/wiki/Test-driven_development The main aspects I am thinking of here are in testability and API design. If we have some code that can't be tested, then it is a sign that the code needs to be re-worked. Specifically here it would appear that the code is doing too much "all-in-one" and could benefit from some modular breakup. In this specific case, the persistence of the preferences can be split up. For some testing of the preferences class I would think that some testing should be on the actual setting and fetching of values. A *separate* set of testing can focus on the actual backing store of things that currently persist to a file. I would rank this as even more appropriate for these classes since the stated design intent is to have the ability to hook to different backing down the road. So for a quick overview of factors to look a to try to glean an idea of what might be done in this case: * Look at splitting the backing store from the main class that others use. (a singleton/facade helps us here) * Consider having the unit tests run with the XDG environment set to point to other locations. (less desirable) * Consider a *compile-time* flag to have an explicit file used for the preferences when inside a unit test, instead of the fallback defaults * Some other unit tests might benefit from a preferences instance that either breaks in determined ways or reads from some canned setup. Splitting the backing store might be a bit more work than we need now. The XDG environment variables *could* be used to affect testing, but that's probably not as stable of an approach. I think compile-time flags to enable "read-only" and/or "read from a special .xml" might be the most helpful. The "read-only" mode should work for most tests, but reading from an explicit file might allow tests to be run using canned data. If you have a bit of time to look at this, one of the things I've done in the past on other projects is some simple changes to add a call that will clear out the preference type objects and fill them from an explicit file. This makes it very easy to switch starting state of things on a case-by-case basis even if multiple tests are run inside of a single executable. Let me know if this has helped you start to get some ideas. We probably should bounce things around a bit in the chat room, then get some details up on the wiki so that others can have guidelines as they work on other code too. Thanks.

2 1

Discoverablity of kerned text
by unknown＠example.com 13 Mar '10

13 Mar '10

Hi all, I recently had a problem with text that was kerned manually without me knowing it. It would probably have helped if there were some small indicator that it was 'manually kerned'. Things I can come up with: - change color of textbox when using the texttool - add small indicator to the textbox Anybody else have an idea? Thanks, Johan

3 2

uniconvertor on windows
by Alexandre Prokoudine 13 Mar '10

13 Mar '10

Hi, Igor has just mailed me that a new version of UniConvertor (1.1.5) will be out soon. Here is what you (win32 packagers and users) need to know. 1. First of all, Inkscape currently ships older version of UC - 1.1.3, whereas the actual one is 1.1.4. 2. The new Windows build of UC will be *much* larger (around 50Mbyte), so he's thinking about doing a special, smaller build for Inkscape, stripped of Python (IIRC). 3. The new version of UC is tuned for VisualStudio 2008 which allows 64bit builds, whereas Inkscape seems to rely on mingw (no 64bit, as he states). This might be problematic for Windows packagers. If you need any details, please mail him. Alexandre

4 4