User:Dresb

Hello, this is a new account I made to fix the "theme issue".
My old username was Z_en_coder, these are my old contributions.

As a (still, sadly) student I use the EFL to experiment with new interface concepts my goal is to introduce a new application development micro-framework that standarizes some behaviors rather than elements.

English is not my first language so feel free to correct my grammar in both my old contributions and my new contributions

Google Summer of Code

Application

Setup the foundations necessary for creating complex GUIs with Edje. By turning Edje into a complete layout engine by the introduction of new part types representing layout structures like vbox, hbox or table. Besides layout it is necessary to include the basics for custom widget creation, particularly list based widgets. Such endeavor would require certain fundamental changes in Evas, most of which are currently being considered, and to complete or update previous work in "esmart_container" and "edje_container".

Current solutions to these problems are provided by two widget libraries, EWL and ETK, which use Edje for their themes. But this approach introduces new problems and limitations that some types of plain Edje applications shouldn't require.

Detailed Description

Even when its possible to create rich GUIs using Edje today. Some functionality, like including buttons in a tool bar, require a certain degree of automation. As it is today, this requires either manual alteration of interface by the designer or the implementation of completely new type of Evas object, like an hbox, by the application developer. The best solution is to standardize the second approach in a way that maintains control by the designer side and removes code duplication in the developer side.

Currently two widget libraries using Edje exist. The problem is that both are implemented as an abstraction over Evas/Edje. This makes integration with a pure Edje application difficult. Both provide an "embed" widget that makes including their widgets into Edje interfaces possible. This does not solve the layout issues that Edje applications face today. The alternative is to use *their* layout system. This forces the designer to surrender the fine grained control over states and transitions in the layout and laid out objects he currently enjoys.

By including new layout specific parts to Edje even hybrid applications embedding widgets from EWL/ETK would benefit with more flexible, thus richer, interfaces. Structures like vbox, hbox, table or flow will be presented to designers in a way familiar to them with additional properties besides those included in "parts" by default.

Concerning widget creation, even when a handful of widgets are trivial to create with a couple of lines of C and an Edje group or two. The rest of the widgets become harder as we approach to list based ones. Lists require many considerations of performance and navigation. An application that needs a list is forced to implement it from the scratch, with varying levels of success. This approach replicates a lot of existing work. Developers could use lists provided by one of the widget libraries and fiddle with the widget's theme to fit their application. But this would force some types of applications to that do not need a full blown widget library to include one.

In order for Edje based applications to retain the biggest degree of flexibility possible, a generic API for list based widgets must follow the Model-View-Controller pattern as described in http://wiki.enlightenment.org/index.php/MVC_List. Once this generic implementation is done it can be used as a base for its Edje equivalent. The Edje version would include the many features specific to the library.

Implementation Details

I will try to describe all the necessary work to complete my goals in this SoC. Keep in mind that shorter descriptions do not mean less work.

Foundations for Layouts

The work on this step has begun already with Gustavo Barbieri implementing the two base objects:

• evas_object_smart_clipped is used to manage groups of Evas objects as one and independently of the intended relationship among them. Actions like deallocating or moving all objects in a group are done with a single function call.
• evas_object_layout uses the previous object as a base to manage a list of Evas object *with* an implied relationship, each Evas object is laid out respectively to it's neighbors, with "neighbor" applying to various extents. All the functionality common among different kinds of layouts is implemented in this Object.

The base evas_object_layout object needs to be completed to support the following style properties:

• margin. Draw an empty area the left, top, right and/or bottom limits of every widget in the container.
• alignment. When objects of different size are placed in the same container the objects can be aligned centrally, to the left/top or the right/bottom.

The base objects will then used to implement the specific layout objects. In this SoC I intend to implement the vbox, hbox, table and flow.

Layouts in Edje Data Collections

Once all layout objects are implemented as Evas Smart Objects it is necessary to update Edje to expose them to the designer. This includes updating the Edje parser/compiler and the Edje runtime loader. A new part type for each kind of layout object will be created. Initially VBOX, HBOX, TABLE and FLOW.

Edje must provide the style properties defined in "Foundations for Layouts" as properties in the description{} block to the designer. As designers will set the size of the layout part using rel1 and rel2 the Edje must also provide fill policies as a property.

Considering the new (still under review) Evas Object Size Hints I will implement the 8 types of fill policies as detailed in EWL Fill policies for each one of the four layout part types in this SoC.

Foundations for MVC Lists

The intended result for this item was clearly documented by Gustavo in MVC_List. Practical work on this item has not begun yet and the specifications might vary slightly. It will be necessary to get esmart_container up to speed and use it as the base.

MVC lists in Edje Data Collections

It will be necessary to revive edje_container.c and alter the parset/compiler and runtime loader to support the new CONTAINER part type that will provide additional parameters to artists and developers using Edje groups as the renderer objects for the rows.

Roadmap

1. April 14 to May 26. Creation of a draft implementation of the critical objects to gather as much feedback from the community as possible while updating the implementation details to fit any unexpected changes. The "draft implementations" might be used directly in the following steps.
2. One to Two weeks. Foundations for Layouts.
3. One to Two weeks. Layouts in Edje Data Collections.
4. Two to Three weeks. Foundations for MVC Lists.
5. Two to Three weeks. MVC lists in Edje Data Collections.

Additional Goals

If the roadmap detailed in the previous section is completed before the end of SoC I intend to work in two additional goals that will help towards the completion of the main objective, "Setup the foundations necessary for creating complex GUIs with Edje".

Abstraction of clipboards and DND

Abstraction of clipboard and drag and drop among different systems. Ecore already implements both for the X server. My goal is to abstract Ecore's implementation and include MacOS X and Windows support. With such abstraction it should be easy for application developers to extend support to additional systems they want to port their program.

Abstraction of the "Viewports"

A "viewport" is used to display different types of data that might be bigger in size than the screen is currently capable of displaying. I hope to implement a viewport Smart Object that sports a plugin system for it's main components.

• Scrollpane. Displays an object. When given two values representing a relative position in a bi-dimensional coordinate system. calculates and alters the area of the object being displayed. Implements the transition between two values. For this to be possible the scrollpane will be provided with:
  • A mechanism to know the size of the viewport in pixels.

• Scroller.A mechanism that calculates a position to be sent to the Scrollpane. For this to be possible the Scroller will be provided with mechanisms to:
  • Access the current position being displayed, in relative coordinates.
  • Access the current proportion Object -> Viewport, in relative coordinates.
  • Access an Evas Object contaning some kind of graphical representation of the object being displayed.

I will complete this additional goal with the creation of three types of scrollpanes and scrollers:

1. A generic Evas Object viewer and a minimap.
2. A simple list with kinetic displacement and a "mouseover" scrolling mechanism.
3. An optimized list and horizontal/vertical scrollbars .

My first book: Development with Edje

I'm currently working on a book about application development with Edje. From the abstract:

An introduction to GUI based application development. Starts from the most basic concepts and introduces the EFL libraries that deal with each of them. It covers Edje, Ecore, Evas and EWL. This book is intended to cover all the concepts needed by a novice programmer to create a full blown GUI application.

You can fetch the docbook files from the cvs in "e17/docs/devwithedje" or download the Pre Rendered versions in HTML and PDF directly from the SVN head.

The content of this book is based on the questions I faced when I tried to develop my first Edje based application so I might be omitting necessary concepts. Feedback is critical for this project become a real book, please post any comments in my talk page or mail me to andresblancMAPSON@NOSPAMgmail.com. Thanks.