Page MenuHomePhabricator

Window Eoapi Design
Updated 985 Days AgoPublic

What, why

The Window API in EO land (and EFL 2) should be a super widget merging the features of:

  • elm_win
  • evas
  • ecore_evas
  • conformant: indicator, soft keys, soft keyboard, clipboard
  • client-side decorations (so forth CSD)
  • background (standard util window)

One reason is the disparity and duplication of APIs in ecore_evas, evas and window is confusing. The other is that conformants seem like an odd after thought, and are easily missed when writing a standard application. The window should handle all that.

Design draft

The window should contain a single edje object of varying styles (or signals enabling / disabling features), with the following slots (SWALLOW). Only the parts in bold [F] are focussable. Exact swallow names to be defined. They will be part of the theme ABI. Each part is a SWALLOW and may or may not be clipped.

Simple design

  • csd
  • bg
  • indicator
  • main_menu [F]
  • content [F]
  • clipboard
  • virtual keyboard
  • soft keys

Complex design

  • csd_shadow
  • csd_title
  • bg
  • below_content [F]
  • indicator
  • main_menu [F]
  • app_title [F]
  • content [F]
  • above_content [F]
  • clipboard
  • virtual keyboard
  • soft keys

Various styles may provide various clippers for the parts, hide and show some parts, or simply not have a specific slot (eg. no csd style could simply not have the csd slot).



Here's a list of required part names based on the work in progress:

  • elm.spacer.opaque for WM hints on the opaque region (app content + top/bottom bars if opaque)
  • elm.spacer.content required to properly size the window (app content including main menu)
  • elm.rect.background for solid color bg
  • elm.swallow.background for swallowed bg object
  • main menu
  • elm.swallow.client to contain the client (currently still a "win" edje object) FIXME rename to "content" and alias client to content

Visibile to apps

  • background supports file, color and content APIs


Both designs drop the concept of resize_object concept and stack. A single widget can be swallowed in as content. bg is not focussable, which means that maybe more than one content slots are required for sizing issues.

  • How to provide different layouts? Signals or styles?
  • How to merge everything without breaking compatibility? (ouch)
  • How to merge the frame for CSD and the conformant and the window into a single group?

API choices

The first guy wins

If elm_win_resize_object_add() is used, then the window behaves in legacy mode. New slots are not allowed. If a content is set, then it behaves in the new mode, and resize_objects are not allowed.

In a standard window (util), the bg will be swallowed in the bg slot.


Two major ways to implement this:

  • Expand and improve elm_win
  • Create a new window class


Here's a todo list, in order to implement this step by step.

  • Implement CSD support in X: first for testing purposes, then we can eventually switch to CSD as a default policy (eg. like GTK3). WORK IN PROGRESS.
  • Create new window edje group "window"
  • Add indicator slot in "window"
  • Add bg slot in "window", use it in std util window
  • Add missing slots: main_menu, app_title, virtual keyboard, soft key, ...
  • Finish the goddamn thing
Last Author
Last Edited
Nov 10 2016, 1:20 AM