Comments on the items so far:
1. Program flow This is a pretty big problem right now. The flow looks like this: - something is updated in the SP tree - updateRepr() is called - new XML is written - XML modification listeners fire - SP tree is re-read from the XML - A recursive call to update() is made - Each of those update calls updates the rendering tree in turn.
As a result, changing the document height triggers a full update of the rendering tree, even though almost nothing changes.
The current approach makes it impossible to introduce errors that cause the XML and the SP tree to go out of sync, at the cost of performance. We could discuss what to do about this.
2. Website The only thing missing for me is regular testing that the scripts for setting up the local copy actually work and don't have to be fixed in subtle ways.
3. Refactoring Yes, yes, yes, yes, and yes Some additional items to consider:
- Unnecessary profileration of namespaces. Things like Inkscape::UI::View::View are excessive. I cannot imagine a scenario where we would need more than 2 levels of namespaces. Everything UI-related should sit in Inkscape::UI, without separate namespaces for widgets and dialogs which only serve to increase typing.
- Directory structure. Let's make a directory for the SP tree, and namespace it as Inkscape::SVG (or maybe Inkscape::DOM).
- Identify clever geometry code which can be cleaned up and moved to 2Geom.
4. Invert coordinate system We need to decide whether we want to keep the 3D Box at all costs, or is the coordinate system inversion a more important goal than having 3D Box. Being unable to fix 3D Box was the main reason I didn't commit this change when I initially made it. FWIW, I think the 3D Box tool is nearly unusable and needs to be rewritten from scratch. It also pollutes the entire codebase with special handling for its perspective elements, indicating faulty design.
5. CMake I would rather use Waf. CMake has its own, sloppy scripting language; writing anything moderately complex in it is an exercise in frustration. By contrast, Waf scripts can leverage all the mighty power of Python.
Killer feature: since Waf stores a database of what was compiled, it support wildcards correctly. As in, when the set of files matched by a wildcard in the build script changes, it will automatically recompiles the correct files, without the need to modify build scripts. CMake cannot do this, because it just generates makefiles, and Make cannot support wildcards in this manner because it does not have any persistence beyond what is stored in the file system.
Other things we could easily do with Waf are: - render test integration - automatically updating the AUTHORS file and the authors tab in the About dialog from Bazaar logs - creating a completely standalone executable (using e.g. GResource to store data files in the executable itself)
I can get this into working state again: https://code.launchpad.net/~tweenk/inkscape/waf-build
Regards, Krzysztof
2015-03-19 22:48 GMT+00:00 Johan Engelen <jbc.engelen@...2592...>:
On 17-3-2015 13:58, Tavmjong Bah wrote:
Hi,
So far we have eight people signed up for the Toronto hackfest. We still have room for more! Our fund raising campaign is doing well. Sponsorship is available for active developers and other Inkscape community members, see:
http://wiki.inkscape.org/wiki/index.php/Hackfest2015_AttendeesI've prepared a "Topics" wiki page to keep track of things that we should discuss and/or work on at the hackfest. Please add your ideas... even if you are not able to attend. The topics page is at:
http://wiki.inkscape.org/wiki/index.php/Hackfest2015_TopicsPerhaps discuss Jenkins/unittesting/rendertesting.
-Johan
Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel