* @ref progressbar_example
*
* @ref slideshow_example
+ *
+ * @ref efl_thread_1
+ *
+ * @ref efl_thread_2
+ *
+ * @ref efl_thread_3
+ *
+ * @ref efl_thread_4
+ *
+ * @ref efl_thread_5
+ *
+ * @ref efl_thread_6
*/
/**
* @until }
*
* The next callback will be used when setting the overlay (using
- * elm_bg_overlay_set()):
+ * elm_object_content_set()):
*
* @skip _cb_overlay_changed
* @until }
*
* @skipline elm_radio_value_set
*
- * Then we add a checkbox for the elm_bg_overlay_set() function:
+ * Then we add a checkbox for the elm_object_content_set() function for the bg:
*
* @skip check_add
* @until evas_object_show
*
* Now look at the code of the @c _cb_overlay_changed again. If the checkbox
* state is checked, an overlay will be added to the background. It's done by
- * creating an Edje object, and setting it with elm_bg_overlay_set() to the
+ * creating an Edje object, and setting it with elm_object_content_set() to the
* background object. For information about what are and how to set Edje
* object, look at the Edje documentation.
*
* callback, where we move the button doing some size hint magic. To
* understand how that works better, refer to the @ref Box documentation.
* Also, the first time the function is called, we change the icon in the
- * middle button, using elm_button_icon_unset() first to keep the reference
+ * middle button, using elm_object_content_unset() first to keep the reference
* to the previous one, so we don't need to recreate it when we are done
* moving it.
* @skip static void
* @until }
*
* This call elm_layout_data_get() is used to fetch the string based on the key,
- * and elm_object_text_part_set() will set the part defined in the theme as
+ * and elm_object_part_text_set() will set the part defined in the theme as
* "example/title" to contain this string. This key "example/title" has nothing
* special. It's just an arbitrary convention that we are using in this example.
* Every string in this example referencing a part of this theme will be of the
* Finally, we have an area in this layout theme, in the bottom part of it,
* reserved for adding an specific widget. Differently from the 2 parts
* described until now, this one can only receive one widget with the call
- * elm_layout_content_set(). If there was already an item on this specific part,
- * it will be deleted (one can use elm_layout_content_unset() in order to remove
+ * elm_object_part_content_set() for the layout. If there was already an item on this specific part,
+ * it will be deleted (one can use elm_object_part_content_unset() in order to remove
* it without deleting). An example of removing it without deleting, but
* manually deleting this widget just after that, can be seen on the callback
* for this button. Actually, the callback defined for this button will clean
* Also notice that, for this last added button, we don't have to call
* evas_object_show() on it. This is a particularity of the theme for layouts,
* that will have total control over the properties like size, position,
- * visibility and clipping of a widget added with elm_layout_content_set().
+ * visibility and clipping of a widget added with elm_object_part_content_set().
* Again, read the Edje documentation to understand this better.
*
* Now we just put the code for the different callbacks specified for each kind
* @until evas_object_show
*
* Finally, we'll set the box as conformant's content, just like this:
- * @skipline elm_conformant_content_set
+ * @skipline elm_object_content_set
*
* Compare both examples code:
* @ref conformant_example_01.c "conformant_example_01.c"
*/
/**
+ * @page web_example_01 Web - Simple example
+ *
+ * WebKit-EFL is independent of any particular toolkit, such as Elementary,
+ * so using it on applications requires that the programmer writes a lot of
+ * boiler plate code to manage to manage the web object.
+ *
+ * For a full featured browser this may make sense, as the programmer will
+ * want to have full control of every aspect of the web object, since it's the
+ * main component of the application. But other programs with simpler
+ * requirements, having to write so much code is undesired.
+ *
+ * This is where elm_web comes in. Its purpose is to provide a simple way
+ * for developers to embed a simple web object in their programs, simplifying
+ * the common use cases.
+ *
+ * This is not to say that a browser can't be made out of it, as this example
+ * shows.
+ *
+ * We'll be making a simple browser, consisting of one window with an URL bar,
+ * a toolbar to be used for the tabs and a pager to show one page at a time.
+ *
+ * When all tabs are closed, we'll be showing a default view with some custom
+ * content, for which we need to get the internal @c ewk_view object and use
+ * some WebKit functions on it, thus we need to include the necessary headers
+ * first.
+ *
+ * @dontinclude web_example.c
+ * @skip include
+ * @until EWebKit
+ *
+ * A struct to keep track of the different widgets in use and the currently
+ * shown tab. There's also an @c exiting flag, used to work around the overly
+ * simplistic way in which this example is written, just to avoid some
+ * warnings when closing the program.
+ *
+ * @skip typedef
+ * @skip typedef
+ * @until App_Data
+ *
+ * Each tab has its own struct too, but there's not much to it.
+ * @until };
+ *
+ * Whenever the currently selected tab changes, we need to update some state
+ * on the application. The back and forward buttons need to be disabled
+ * accordingly and the URL bar needs to show the right address.
+ *
+ * @skip static void
+ * @until pager_content_promote
+ * @until }
+ *
+ * Other updates happen based on events from the web object, like title change
+ * to update the name shown in the tab, and URL change which will update the
+ * URL bar if the event came from the currently selected tab.
+ *
+ * @skip tab_current_set
+ * @skip static void
+ * @until }
+ * @until }
+ *
+ * Adding a new tab is just a matter of creating a new web widget, its data
+ * and pushing it into the pager. A lot of the things that we should handle
+ * here, such as how to react to popups and JavaScript dialogs, are done
+ * already in the @c elm_web widget, so we can rely on their default
+ * implementations. For the JavaScript dialogs we are going to avoid having
+ * them open in a new window by setting the @c Inwin mode.
+ *
+ * There is no default implementation, however, for the requests to create a
+ * new window, so we have to handle them by setting a callback function that
+ * will ultimately call this very same function to add a new tab.
+ *
+ * @skip Tab_Data
+ * @until }
+ *
+ * Entering an address in the URL bar will check if a tab exists, and if not,
+ * create one and set the URL for it. The address needs to conform to the URI
+ * format, so we check that it does and add the protocol if it's missing.
+ *
+ * @skip static char
+ * @until eina_stringshare_del
+ * @until }
+ *
+ * The navigation buttons are simple enough. As for the refresh, it normally
+ * reloads the page using anything that may exist in the caches if applicable,
+ * but we can press it while holding the @c Shift key to avoid the cache.
+ *
+ * @skip static void
+ * @until web_forward
+ * @until }
+ *
+ * The callback set for the new window request creates a new tab and returns
+ * the web widget associated with it. This is important, this function must
+ * return a valid web widget returned by elm_web_add().
+ *
+ * @skip static Evas_Object
+ * @until }
+ *
+ * Pressing @c Ctrl-F will bring up the search box. Nothing about the box
+ * itself is worth mentioning here, but it works as you would expect from any
+ * other browser. While typing on it, it will highlight all occurrences of the
+ * searched word. Pressing @c Enter will go to the next instance and the two
+ * buttons next to the entry will move forward and backwards through the found
+ * keywords.
+ *
+ * @skip win_del_request
+ * @skip static void
+ * @until win_search_trigger
+ * @until }
+ *
+ * Last, create the main window and put all of the things used above in it. It
+ * contains a default web widget that will be shown when no tabs exist. This
+ * web object is not browsable per se, so history is disabled in it, and we
+ * set the same callback to create new windows, on top of setting some custom
+ * content of our own on it, with some links that will open new tabs to start
+ * browsing quickly.
+ *
+ * @skip static void
+ * @until ELM_MAIN
+ *
+ * Some parts of the code were left out, as they are not relevant to the
+ * example, but the full listing can be found at @ref web_example.c
+ * "web_example.c".
+ *
+ * @example web_example.c
+ */
+
+/**
+ * @page efl_thread_1 EFL Threading example 1
+ *
+ * You can use threads with Elementary (and EFL) but you need to be careful
+ * to only use eina or eet calls inside a thread. Other libraries are not
+ * totally threadsafe except for some specific ecore calls designed for
+ * working from threads like the ecore_pipe_write() and ecore_thread calls.
+ *
+ * Below is an example of how to use EFL calls from a native thread you have
+ * already created. You have to put the EFL calls inside the critical block
+ * between ecore_thread_main_loop_begin() and ecore_thread_main_loop_end()
+ * which ensure you gain a lock on the mainloop. Beware that this requires
+ * that the thread WAIT to synchronize with the mainloop at the beginning of
+ * the critical section. It is highly suggested you use as few of these
+ * in your thread as possible and probably put just a single
+ * ecore_thread_main_loop_begin() / ecore_thread_main_loop_end() section
+ * at the end of the threads calculation or work when it is done and
+ * would otherwise exit to sit idle.
+ *
+ * For a progression of examples that become more complex and show other
+ * ways to use threading with EFL, please see:
+ *
+ * @ref efl_thread_2
+ *
+ * @ref efl_thread_3
+ *
+ * @ref efl_thread_4
+ *
+ * @ref efl_thread_5
+ *
+ * @ref efl_thread_6
+ *
+ * @include efl_thread_1.c
+ */
+
+/**
+ * @page efl_thread_2 EFL Threading example 2
+ *
+ * You can also use ecore_main_loop_thread_safe_call_sync() to call a
+ * specific function that needs to do EFL main loop operations. This call
+ * will block and wait to synchronise to the mainloop just like
+ * ecore_thread_main_loop_begin() / ecore_thread_main_loop_end() will,
+ * but instead you simply provide it the function callback to call instead
+ * of inlining your code.
+ *
+ * @ref efl_thread_3
+ *
+ * @ref efl_thread_4
+ *
+ * @ref efl_thread_5
+ *
+ * @ref efl_thread_6
+ *
+ * @include efl_thread_2.c
+ */
+
+/**
+ * @page efl_thread_3 EFL Threading example 3
+ *
+ * Like with ecore_main_loop_thread_safe_call_sync() you can provide a
+ * callback to call inline in the mainloop, but this time with
+ * ecore_main_loop_thread_safe_call_async() the callback is queued and
+ * called asynchronously, without the thread blocking. The mainloop will
+ * call this function when it comes around to its synchronisation point. This
+ * acts as a "fire and forget" way of having the mainloop do some work
+ * for a thread that has finished processing some data and is read to hand it
+ * off to the mainloop and the thread wants to march on and do some more work
+ * while the main loop deals with "displaying" the results of the previous
+ * calculation.
+ *
+ * @ref efl_thread_4
+ *
+ * @ref efl_thread_5
+ *
+ * @ref efl_thread_6
+ *
+ * @include efl_thread_3.c
+ */
+
+/**
+ * @page efl_thread_4 EFL Threading example 4
+ *
+ * Now when you want to have a thread do some work, send back results to
+ * the mainloop and continue running but the mainloop controls when the
+ * thread should stop working, you need some extra flags. This is an example
+ * of how you might use ecore_main_loop_thread_safe_call_async() and pthreads
+ * to do this.
+ *
+ * @ref efl_thread_5
+ *
+ * @ref efl_thread_6
+ *
+ * @include efl_thread_4.c
+ */
+
+/**
+ * @page efl_thread_5 EFL Threading example 5
+ *
+ * This is the same as @ref efl_thread_4 but now uses the ecore_thread
+ * infrastructure to have a running worker thread that feeds results back
+ * to the mainloop and can easily be cancelled. This saves some code in the
+ * application and makes for fewer problem spots if you forget a mutex.
+ *
+ * @ref efl_thread_6
+ *
+ * @include efl_thread_5.c
+ */
+
+/**
+ * @page efl_thread_6 EFL Threading example 6
+ *
+ * You can also use the ecore_thread infrastructure for compute tasks that
+ * don't send feedback as they go - they are one-shot compute jobs and when
+ * done they will trigger the end callback in the mainloop which is intended
+ * to pick up the results and "display them".
+ *
+ * @include efl_thread_6.c
+ */
+
+/**
* @page bg_example_01_c bg_example_01.c
* @include bg_example_01.c
* @example bg_example_01.c
* @include slideshow_example.c
* @example slideshow_example.c
*/
+
+/**
+ * @page efl_thread_1_c EFL Threading example 1
+ * @include efl_thread_1.c
+ * @example efl_thread_1.c
+ */
+
+/**
+ * @page efl_thread_2_c EFL Threading example 2
+ * @include efl_thread_2.c
+ * @example efl_thread_2.c
+ */
+
+/**
+ * @page efl_thread_3_c EFL Threading example 3
+ * @include efl_thread_3.c
+ * @example efl_thread_3.c
+ */
+
+/**
+ * @page efl_thread_4_c EFL Threading example 4
+ * @include efl_thread_4.c
+ * @example efl_thread_4.c
+ */
+
+/**
+ * @page efl_thread_5_c EFL Threading example 5
+ * @include efl_thread_5.c
+ * @example efl_thread_5.c
+ */
+
+/**
+ * @page efl_thread_6_c EFL Threading example 6
+ * @include efl_thread_6.c
+ * @example efl_thread_6.c
+ */
projects / framework / uifw / elementary.git / blobdiff