- User Since
- Aug 18 2014, 10:09 AM (208 w, 3 d)
Tue, Aug 14
Tue, Aug 7
Jul 11 2018
Jul 9 2018
Jul 3 2018
Jun 21 2018
May 2 2018
Apr 30 2018
Mar 6 2018
Roadmaps are often extremely valuable, although depending on how they're handled they can also be a source of some contention or confusion.
Feb 14 2018
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.
Jan 30 2018
Jan 23 2018
Dec 13 2017
- 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
Nov 28 2017
This is pretty trivial but at least shows solution to the previously mentioned issues. :-)
Nov 22 2017
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.
Nov 21 2017
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.
Nov 20 2017
Nov 19 2017
Nov 18 2017
Nov 13 2017
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.
Nov 12 2017
Nov 10 2017
Nov 9 2017
Nov 8 2017
Nov 7 2017
Nov 3 2017
Build failure is spurious again; build timed out after 10 min I guess.
Oct 31 2017
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.
Oct 30 2017
Oct 27 2017
- eina: Spellfix api doxygen (C-F)
Oct 26 2017
Oct 24 2017
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.
Oct 17 2017
Oct 13 2017
Oct 10 2017
Be a bit more consistent in wording for the matrix parameter docs
Fix grammar in doxygen
Fix misspelling 'determinante'
Oct 9 2017
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: