Roadmaps are often extremely valuable, although depending on how they're handled they can also be a source of some contention or confusion.

Ah true, if dst is passed as a pointer to m1 or m2 then the results of the earlier calculations interfere with the latter ones.

• eina: Further clarify quadtree docs

[10:48:58] <cedric> an object in the quadtree can be visible or not
[10:49:06] <cedric> if it is not visible, it won't intersect
[10:49:20] <cedric> there is a cost of removing an object from the stack
[10:49:30] <cedric> so instead of removing it, you can mark it invisible

[10:22:44] <cedric> bryce, i don't know for cycle what was the purpose of it
[10:22:48] <cedric> it is part of the test...
[10:23:46] <cedric> as for the callback function, you are right, it is for sorting

This is pretty trivial but at least shows solution to the previously mentioned issues. :-)

It's going slow. I've gotten the codebase started but am blocked by trying to figure out how to use the Eo API for instantiating a Cairo canvas, of all things. This maze game is essentially going to be a port of an prior (non-EFL) game I had half finished, so once I have a canvas in place I think progress will be faster. I've been trying to get the code pushed to the examples repo, but I still don't seem to have write access so that's been a bit of a blocker, but I can just push to github I suppose; there's been some directory changes to the examples repo, so I need to rebase my current work to account for that first.

Cedric, I had to make some (lightly) educated guesses about how eina_quadtree_collide() works, so please review those docs in particular.

The build error is spurious, again.

The diff attached to https://phab.enlightenment.org/D5468 shows the doxygen style to follow. Specifically, I've derived the following rules-of-thumb from examining the existing style of the Eina and Evas doxygen in the codebase, to try and standardize on. Please let me know if any adjustments need made to these.

Build failure is spurious again; build timed out after 10 min I guess.

Build failure is spurious again, and unrelated to the changes. From the log it appears to maybe be hitting a 10 min timeout?

Build failure appears to be spurious and unrelated to this change.

• eina: Spellfix api doxygen (C-F)

It may be worthwhile to split this task into per-module subtasks, as the documentation effort will want to prioritize examples for certain modules over others.

There are examples for most or all of the main EFL modules, although their discoverability might be improved. Navigating from https://docs.enlightenment.org/auto/, each link goes to a top level description of a given module, often along with an introductory example or two. Typically, the final sentence of these pages points to a page with additional examples.

Be a bit more consistent in wording for the matrix parameter docs

Fix grammar in doxygen

Fix misspelling 'determinante'

If Tizen has docs that are felt to be suitable, then yes definitely. However, my guess is their docs are bitrotting and will be difficult to get updated, so would suggest having something maintained as part of EFL's docs (even if it just copies or cross references the Tizen docs in many places). Not having gone through creation & deployment of a Tizen app myself, I couldn't vouch for the quality of their docs, but they felt a bit lightweight to me.

Sample code snippets for each might be nice too. I'm thinking of something along the lines of https://www.cairographics.org/samples/, which I've always found handy.

The style of the auto/ page could certainly be improved, but the layout is probably far more important to achieve readability. As I see it there are several things to do:

Some workflow steps, apart from the actual coding of the project, which might be worth considering providing docs for at some point.

Some ideas for example projects:

As someone that just got into EFL recently myself, Cedric asked me for some getting started recommendations for new tech writers as they onboard.