raster pushed a commit to branch master.
http://git.enlightenment.org/website/www-content.git/commit/?id=1dfd7faeb099b292f6adc00ea94705d89c7fe335
commit 1dfd7faeb099b292f6adc00ea94705d89c7fe335
Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com>
Date: Fri Apr 24 18:08:49 2015 +0900
wiki content - use new code lang declaration to use auto-linking
also remove manual '' '' monispacing of tokens and let codelink do it.
---
pages/docs/efl/ref/c/key/evas_object_del.txt | 11 ++++++-----
pages/docs/efl/ref/c/key/evas_object_ref.txt | 7 ++++---
pages/docs/efl/start.txt | 25 ++++++++++++++-----------
3 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/pages/docs/efl/ref/c/key/evas_object_del.txt
b/pages/docs/efl/ref/c/key/evas_object_del.txt
index 73b7114..2cc5d2c 100644
--- a/pages/docs/efl/ref/c/key/evas_object_del.txt
+++ b/pages/docs/efl/ref/c/key/evas_object_del.txt
@@ -1,4 +1,5 @@
~~Title: evas_object_del()~~
+~~CODE-c~~
<code c>
void evas_object_del(Evas_Object *obj)
</code>
@@ -12,18 +13,18 @@ collected by the rendering of the canvas. This will also
hide the
object, if it has been shown.
Note that if the object has more references (created by
-''evas_object_ref()'' and ''evas_object_unref()'' for example), then
+evas_object_ref() and evas_object_unref() for example), then
deletion will wait until all these references have been given up with
-''evas_object_unref()''.
+evas_object_unref().
If the object has no outstanding references, at this point the
-''EVAS_CALLBACK_DEL'' callback will be called on this object, informing
+EVAS_CALLBACK_DEL callback will be called on this object, informing
all listeners of the callback of this deletion. At a later point when
-the object is actually really cleaned up, the ''EVAS_CALLBACK_FREE''
+the object is actually really cleaned up, the EVAS_CALLBACK_FREE
event callback will get called.
If the object had the focus at the time of deletion, the
-''EVAS_CALLBACK_FOCUS_OUT'' event callbacks will also be called at this
+EVAS_CALLBACK_FOCUS_OUT event callbacks will also be called at this
time.
Note that all objects contained in an Evas canvas are deleted when the
diff --git a/pages/docs/efl/ref/c/key/evas_object_ref.txt
b/pages/docs/efl/ref/c/key/evas_object_ref.txt
index 1def77f..3682f73 100644
--- a/pages/docs/efl/ref/c/key/evas_object_ref.txt
+++ b/pages/docs/efl/ref/c/key/evas_object_ref.txt
@@ -1,10 +1,11 @@
~~Title: evas_object_ref()~~
+~~CODE-c~~
<code c>
void evas_object_ref(Evas_Object *obj)
</code>
This increments the reference count of the object ''obj'', which, if greater
-than 0, will defer deletion by ''evas_object_del()'' until all references
+than 0, will defer deletion by evas_object_del() until all references
are released back (counter back to 0). References cannot go below 0 and
unreferencing past that will result in the reference count being limited to
0. References are limited to //(2^32) -1// for an object. Referencing it
@@ -15,8 +16,8 @@ instance, Evas is not ready to check for pending references
on a
canvas deletion, or things like that. This is useful in scenarios
where, inside a code block, callbacks exist which would possibly
delete an object we are operating on afterwards. Then, one would
-''evas_object_ref()'' it at the beginning of the block and
-''evas_object_unref()'' it at the end. It would then be deleted at
+evas_object_ref() it at the beginning of the block and
+evas_object_unref() it at the end. It would then be deleted at
this point, if it should be.
== Example ==
diff --git a/pages/docs/efl/start.txt b/pages/docs/efl/start.txt
index 809c148..1aa9b5b 100644
--- a/pages/docs/efl/start.txt
+++ b/pages/docs/efl/start.txt
@@ -1,4 +1,5 @@
~~Title: EFL~~
+~~CODE-c~~
==== EFL ====
@@ -61,13 +62,15 @@ design pattern.
An application would spend almost it's entire life inside the
__Mainloop__ sleeping, processing events and then updating it's UI,
until it decides to exit. All of this would take place inside the
-__Mainloop__ processing function ''elm_run()'' which will only return
-once the __Mainloop__ voluntarily exits if an ''elm_exit()'' function is
+__Mainloop__ processing function elm_run() which will only return
+once the __Mainloop__ voluntarily exits if an elm_exit() function is
called while it runs, which marks the loop to exit, next time it has a
chance. Before and after this, will be initialization and shutdown of the
application. Your most basic application that just does nothing but
wait forever for events would be:
+elm_exit
+
<code c example.c>
#include <Elementary.h>
@@ -119,10 +122,10 @@ elm_main(int argc, char **argv)
ELM_MAIN()
</code>
-When the application runs, the ''ELM_MAIN()'' macro sets up a normal
-''main()'' function, inits EFL for you and then calls elm_main() with
+When the application runs, the ELM_MAIN() macro sets up a normal
+main() function, inits EFL for you and then calls elm_main() with
the usual application argc & argv parameters you get in C. When
-''elm_main()'' returns, it will pass the return value to the return
+elm_main() returns, it will pass the return value to the return
value of main() for the application exit code. Before it does this,
EFL will be cleanly shut down for you. You are encouraged to use this
setup above to ensure this happens.
@@ -132,7 +135,7 @@ elm_policy_set(ELM_POLICY_QUIT,
ELM_POLICY_QUIT_LAST_WINDOW_CLOSED);
</code>
The first thing we do is enable a policy where if our last window is
-deleted, the __Mainloop__ started by ''elm_run()'' is automatically
+deleted, the __Mainloop__ started by elm_run() is automatically
quit when this last window is closed. This is really handy for
applications with multiple windows that want to just go away when they
are no longer presenting any UI.
@@ -238,17 +241,17 @@ elm_run();
</code>
Finally we begin the __Mainloop__. This function will not exit until
-the __Mainloop__ is done and exits (with an ''elm_exit()'' being
+the __Mainloop__ is done and exits (with an elm_exit() being
called from inside some callback there). So at this point your
application is handing full control over it's execution to EFL and the
__Mainloop__ to deal with events and rendering of updates.
----
-**NOTE**: If you don't want to use ''ELM_MAIN()'', you can use
-''elm_init()'' and ''elm_shutdown()'' manually yourself. You **MUST**
-call ''elm_init()'' before you call any EFL functions. It could fail
-too. Also never call any EFL functions after ''elm_shutdown()''.
+**NOTE**: If you don't want to use ELM_MAIN(), you can use
+elm_init() and elm_shutdown() manually yourself. You **MUST**
+call elm_init() before you call any EFL functions. It could fail
+too. Also never call any EFL functions after elm_shutdown().
<code c example.c>
#include <Elementary.h>
--
