NO! this breaks compiling anything against elementary UNLESS you
enable eo beta api support. NO NO NO NO.
This reverts commit cad6de2a8ef93d994f9dedb8e980efe5fbf6d77e.
Summary:
Added to Entry new signal "validate", this signal called from entry every
time when the text inputed to entry.
The regex validation add as elm_helper.
The styles of Entries scrollers are changed to allow highlightion that
is needed by regex processing.
For use regex with entry need register the regex helper as callback
to event: ELM_ENTRY_EVENT_VALIDATE
@feature
Test Plan:
See elementary_test "Entry Regex" test.
Note: when the string matches to regex the highlighting (green) is reset on unfocusing.
Reviewers: herdsman, raster, cedric, tasn
Reviewed By: cedric, tasn
Subscribers: seoz
Differential Revision: https://phab.enlightenment.org/D2043
Summary:
Change requested by TAsn. Previuosly AT-SPI headers were kept private
and included directly into elementary source code. From now on,
AT-SPI headers can be included from Elementary.h public header, however
will be marked as beta APIs.
Commit includes following changes:
* include all atspi headers into new elm_interfaces.h header.
* marking all at-spi interfaces methods/properties as @protected.
* wrap all common headers with EFL_BETA_API_SUPPORT.
* make some common APIs visible in lib, by adding EAPI attribute
(if someone decides to use beta APIs).
Test Plan: out-off tree build with gcc, g++
Reviewers: tasn
Reviewed By: tasn
Subscribers: seoz, q66, kuuko
Maniphest Tasks: T1721
Differential Revision: https://phab.enlightenment.org/D1528
Summary:
Allow to create ATSPI aware objects only by attaching Atspi interface to
Eo object. Apply protected rule to all methods, properties which should
not be available to app developer. Remove public atspi header from Elementary.h.
Make Elm_Widget inherit from Atspi interfaces, Elm_Win inherits additional
Atspi_Window interface.
Unified file names - all atspi related objects/interfaces can be found under
elm_atspi_*
and elm_interface_atspi_*.
Test Plan:
build&install, out-off tree example compilation with gcc and g++,
Orca screen reader tests on Ubuntu 12.04.
Reviewers: raster, seoz, tasn, JackDanielZ
Differential Revision: https://phab.enlightenment.org/D718
Since rELM166ca9e86a72, I moved EWebKit header into Elementary.h like other libraries.
But, it made possible build break while building test browser in webkit.
It's because EWebKit.h and EWebKit2.h have same symbols and test browser should
be compiled with EWebKit2.h although Elementary was built with ewebkit.
This patch reverts a part of changes in rELM166ca9e86a72, which includes EWebkit.h
in Elementary.h
This is the specific error:
/usr/include/elementary-1/Elementary.h:169:24: fatal error: elm_access.h: No such file or directory
Accessibility support was previously disabled by commit
0d61121ce4f87c9e9b0e8d8d7975f815328fe6f5
This is the first commit of the headers split phase in elementary.
Now, each widget will have 2 or 3 h files:
- widget_Eo.h: Eo API functions (functions defines, enums, base id).
- widget_Legacy.h: contains the API functions related to objects
- widget_Common.h: common data (structs, enums...) + functions not related to
objects. This file will exist only if needed.
This phase is needed for the EFL 1.8 release to disable Eo APIs if we
consider it is not enough mature to be used by applications.
For now, it supports only one system tray icon per application.
Each instance of ELM_OBJ_SYSTRAY_CLASS is a handler for
the same system tray item. But the API is ready to support
multiple system tray items per application.
Also, since this is a new feature, it only provides an EObject API. So,
if the old style API is still required, please do it.
Patch by: Murilo Belluzzo <murilo.belluzzo@profusion.mobi>
SVN revision: 81747
i would like to export an API which name is elm_access_external_info_set(Evas_Object *, const char*);
this will be using by application side to set additional accessibility information.
widget could have different information which could be different in another context.
for example: there would be an entry which is for user ID, and there would be another entry which is for password.
in this case, developer would like to add additional information for each entry as below.
entry for user id reads "entry (default information), this entry is for user id (additional information)"
entry for password reads "entry, this entry is for password"
for this reason, i have attached patch. please review the patch and give feedbacks.
SVN revision: 80339
v1 is now deprecated (EINA_DEPRECATED) but still there, should still
work and not break any existing app.
v2 is now there as well, all software is being ported to use it
now. Just Enlightenment itself will still ship with v1 and as soon as
we release it will go v2, we have the patches here.
SVN revision: 80110
The prefs widgets aims to aid with the implementation of
preference/configuration windows/UI elements in Elementary-based
applications (think of Enlightenment configuration dialogs,
elementary_config, etc).
Prefs is a widget that populates its view with widgets
bound to data types (following the instructions of a ".epb" file that
describes a set of items) and handles the storage/restoration of such
data on a configuration file automatically.
There's also the prefs_data handle, which is the one dealing with
user saved data for a given epb defaults set.
The documentation on the new widget is rich (we have examples and even
an EPC reference) and there's a new test entry for it.
I'm blogging about it soon, with screeshots and more details.
Enjoy.
ps.: This is a team work by Murilo Belluzzo, Ricardo de Almeida and me.
SVN revision: 79909
Hi Raster,
Please find the modified patch after the suggested changes.
[ APIs are provided for setting week_start, weekend_start & weekend_length.Default values are fetched
from elm_config instead of edc styles.]
Please review the patch and push it to svn.
Thanks,
Sumanth
Signed-Off-By: Sumanth Krishna Mannam(sumanth.m@samsung.com)
SVN revision: 68868