summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRobin H. Johnson <robbat2@gentoo.org>2015-08-08 13:49:04 -0700
committerRobin H. Johnson <robbat2@gentoo.org>2015-08-08 17:38:18 -0700
commit56bd759df1d0c750a065b8c845e93d5dfa6b549d (patch)
tree3f91093cdb475e565ae857f1c5a7fd339e2d781e /media-libs/edje/metadata.xml
downloadgentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.tar.gz
gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.tar.bz2
gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.zip
proj/gentoo: Initial commit
This commit represents a new era for Gentoo: Storing the gentoo-x86 tree in Git, as converted from CVS. This commit is the start of the NEW history. Any historical data is intended to be grafted onto this point. Creation process: 1. Take final CVS checkout snapshot 2. Remove ALL ChangeLog* files 3. Transform all Manifests to thin 4. Remove empty Manifests 5. Convert all stale $Header$/$Id$ CVS keywords to non-expanded Git $Id$ 5.1. Do not touch files with -kb/-ko keyword flags. Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> X-Thanks: Alec Warner <antarus@gentoo.org> - did the GSoC 2006 migration tests X-Thanks: Robin H. Johnson <robbat2@gentoo.org> - infra guy, herding this project X-Thanks: Nguyen Thai Ngoc Duy <pclouds@gentoo.org> - Former Gentoo developer, wrote Git features for the migration X-Thanks: Brian Harring <ferringb@gentoo.org> - wrote much python to improve cvs2svn X-Thanks: Rich Freeman <rich0@gentoo.org> - validation scripts X-Thanks: Patrick Lauer <patrick@gentoo.org> - Gentoo dev, running new 2014 work in migration X-Thanks: Michał Górny <mgorny@gentoo.org> - scripts, QA, nagging X-Thanks: All of other Gentoo developers - many ideas and lots of paint on the bikeshed
Diffstat (limited to 'media-libs/edje/metadata.xml')
-rw-r--r--media-libs/edje/metadata.xml46
1 files changed, 46 insertions, 0 deletions
diff --git a/media-libs/edje/metadata.xml b/media-libs/edje/metadata.xml
new file mode 100644
index 000000000000..c360c1c28536
--- /dev/null
+++ b/media-libs/edje/metadata.xml
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
+<pkgmetadata>
+<herd>enlightenment</herd>
+<use>
+ <flag name='cache'>Enable caching</flag>
+</use>
+<longdescription>
+Edje is a complex graphical design and layout library.
+
+It's purpose is to be a sequel to "Ebits" which to date has serviced the needs of
+Enlightenment development for version 0.17. The original design paramteres under
+which Ebits came about were a lot more restricted than the resulting use of them,
+thus Edje was born.
+
+Edje is a more complex layout engine compared to Ebits. It doesn't pretend to do
+containering and regular layout like a widget set. It still inherits the more
+simplistic layout ideas behind Ebits, but it now does them a lot more cleanly,
+allowing for easy expansion, and the ability to cover much more ground than Ebits
+ever could. For the purposes of Enlightenment 0.17, Edje should serve all the
+purposes of creating visual elements (borders of windows, scrollbars, etc.) and
+allow the designer the ability to animate, layout and control the look and feel of
+any program using Edje as its basic GUI constructor. This library allows for
+multiple collections of Layouts in one file, sharing the same image database and
+thus allowing a whole theme to be conveneintly packaged into 1 file and shipped
+around.
+
+Edje, unlike Ebits, separates the layout and behavior logic. Edje files ship with an
+image database, used by all the parts in all the collections to source graphical
+data. It has a directory of logical part names pointing to the part collection entry
+ID in the file (thus allowing for multiple logical names to point to the same part
+collection, allowing for the sharing of data betwene display elements). Each part
+collection consists of a list of visual parts, as well as a list of programs. A
+program is a conditionally run program that if a particular event occurs (a button
+is pressed, a mouse enters or leaves a part) will trigger an action that may affect
+other parts. In this way a part collection can be "programmed" via its file as to
+hilight buttons when the mouse passes over them or show hidden parts when a button
+is clicked somewhere etc. The actions performed in changing from one state to
+another ar also allowed to transition over a period of time, allowing animation.
+
+This separation and simplistic event driven style of programming can produce almost
+any look and feel one could want for basic visual elements. Anything more complex is
+likely the domain of an application or widget set that may use Edje as a conveneient
+way of being able to configure parts of the display.
+</longdescription>
+</pkgmetadata>