On Tue, 2015-03-17 at 22:23 -0700, Bryce Harrington wrote:

Maybe the time right after lunch on that last day, we do a review of recently added new features, and then invite users to "show us your usage" and do some live UX analysis?

That would be an ideal scheduling opportunity. Early LGM attendees would have something to do and we can see where we are with technicals and wind down anyone who's stressed over code :-)

Martin,

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_Attendees

I'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_Topics

Perhaps 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

2015-03-20 10:32 GMT+01:00 Tavmjong Bah <tavmjong@...8...>:

On Thu, 2015-03-19 at 23:13 +0000, Krzysztof Kosiński wrote:

...

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.

Do you have a better design in mind?

Why can't the 3D Box be fixed?

It writes out desktop coordinates to the XML instead of document coordinates. We would need to fix up the XML, similar to what we did for guides. Even when that is fixed, there is the problem of chirality of the coordinate system - the sides of the 3D Box are switched around.

There are also some UI issues, for instance there doesn't seem to be any easy way to specify whether you want to create a 3D box in an existing perspective or create a new one.

It's not clear to me whether these issues can be effectively addressed without a rewrite, so if we could decide whether inverting coordinates or preserving 3D box is more important, we would have a contingency plan.

Regards, Krzysztof

On Thu, Mar 19, 2015 at 11:13:52PM +0000, Krzysztof Kosiński wrote:

Comments on the items so far:

5. CMake

I would rather use Waf.

Yeah, we know. :-)

My goal was to have us get some hands on experience with CMake in practice, so we could make an informed decision down the road. But I'm hearing a lot of people voicing support for cmake so maybe this would be a good time to hash it out. Then we can do the actual transition at the hackfest.

To me, the key requirements are perhaps less technical:

* Is it widely known? Can we expect distros and businesses using Inkscape to already know it? How likely will new developers coming to the project already know it?

* Will mastery of it benefit the engineer for their work beyond our project? Will it be worthwhile for gsoc students to learn? Will we be able to use the skill in our own day jobs?

* Is it portable to a wide range of systems? At a minimum it should support Windows/OSX/Linux. Mobile (Android/iPhone/Tizen) portability would give us future flexibility.

CMake hits all the points. Automake is ok for the first two but not so much on the third. Waf might be ok on the third (I don't know), and debatable on the second, but definitely fails the first.

In chatting with others on the project, cmake seems to be everyone's general preference. I know kk is passionate for waf; anyone else?

I'd also like to hear if there's anyone who thinks we should *not* change from automake.

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.

I like how with cmake, I find myself naturally compartmentalizing tests, reusing other people's cmake recipes, and in general being a lot more organized in laying out my cmake logic.

Sure, python is a great scripting language, but one could argue if you need a full bore scripting language to build your software, you've got a more serious problem than choice of build systems...

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)

My suspicion is all those things could probably be done one way or another with any build system. ;-)

And by going with cmake, there's a good chance someone's already sorted out how to do it, and we can just reuse their work. ;-)

Bryce

On Sun, Mar 22, 2015 at 12:07:53AM -0400, Martin Owens wrote:

On Sat, 2015-03-21 at 17:05 -0700, Bryce Harrington wrote:

...

I like how with cmake, I find myself naturally compartmentalizing tests, reusing other people's cmake recipes, and in general being a lot more organized in laying out my cmake logic.

They're all terrible. But which ever ONE is picked, blessed is the project with simple instructions that can train new people into the skill rather than face them with a daunting wall of repetitive and nonsensical codeons.

Right, our current system, with four different build systems, is a bit over the top. It also inhibits us helping each other since folks on one platform aren't as familiar with the build tools on the other platform.

For example. Instruct all people to build all those extra build files in a separate directory. Less there be confusion between build system files in the repository and generated build system files outside of it.

I'd go a step further and say it'd be nice if Inkscape could not only be built in a parallel tree, but also be runnable from the build tree (i.e. without having been installed).

Bryce

On Sun, Mar 22, 2015 at 12:44 AM, Krzysztof Kosiński <tweenk.pl@...2179......> wrote:

Surely Python is more widely known than the CMake scripting language, and learning Python is more generally useful than learning the CMake language.

Waf works everywhere Python is available, so the third point shouldn't be a problem.

...

Sure, python is a great scripting language, but one could argue if you need a full bore scripting language to build your software, you've got a more serious problem than choice of build systems...

You already need a very complex program to build your software: the compiler. Adding some scripts on top of that doesn't significantly change the situation, and having a real scripting language at your disposal is useful more often than one would expect.

I think the problem with having a scripting language as a build system is that 99% of the time you end up reinventing the code http://miller.emu.id.au/pmiller/books/rmch/ that the build system was actually made to solve.

Wildcards cannot be properly supported by anything that generates makefiles.

For example, let's say you have a program which is compiled from main.cpp, plugin-a.cpp, plugin-b.cpp and plugin-c.cpp. The plugin files add some objects to a container by using static initialization (this is a common pattern and is also used in our own code). Let's say you don't want plugin-c.cpp anymore and you delete it. When using CMake or Autotools, which ultimately rely on make, it would not cause a relinking, because all prerequisites still have timestamps that are earlier than the one on the program executable. By contrast, Waf will correctly trigger a relinking in this case.

Except I got rid of all the static initialization that the linker would normally throw out, and moved construction of objects to a factory file. So this point is somewhat moot for Inkscape now. (abusing static initialization will probably end up causing obscure problems http://yosefk.com/c++fqa/fqa.html#fqa-10.12)

On Thu, 2015-03-19 at 23:13 +0000, Krzysztof Kosiński wrote:

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.

That is true for the default setup. CMake can also build ninja files which do a pretty awesome job of building quickly and managing the database of dependencies. I like using CMake's Makefile support for reliable builds, but the ninja option for development is definitely a plus.

Ted