[EGIT] [core/enlightenment] master 01/01: elm integration improvement - copy themes over, fix includes and null config
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=a1d1e4055924cf2369804239a5b7c212d9257ccd
commit a1d1e4055924cf2369804239a5b7c212d9257ccd
Author: Carsten Haitzler (Rasterman)
Date: Fri Nov 1 15:53:05 2013 +0900
elm integration improvement - copy themes over, fix includes and null config
provide a config upgrade path to version 13 which nulls/frees out
theme config (save memory - but more housekeeping), and that also
copeis ofer all files in ~/.e/e/themes to ~/.elementary/themes so you
don't lose themes you personally have and deletes the old e theme dir
if this succeeds.
also remove all #includes of Elementary.h and Emotion.h from single c
files as they are requirements now and in e.h
also remove theme path vars and code as theme path is no longer used.
---
src/bin/e.h| 2 ++
src/bin/e_config.c | 42 ++
src/bin/e_config.h | 4 +--
src/bin/e_init.c | 1 -
src/bin/e_main.c | 20 ---
src/bin/e_theme.c | 1 -
src/bin/e_utils.c | 1 -
src/bin/e_widget_filepreview.c | 1 -
src/bin/e_win.c| 2 --
src/modules/conf2/e_mod_main.h | 2 --
src/modules/conf_paths/e_int_config_paths.c| 24 ++---
src/modules/conf_theme/e_int_config_theme.c| 10 +-
src/modules/conf_theme/e_int_config_theme_import.c | 1 -
src/modules/conf_theme/e_mod_main.c| 1 -
src/modules/teamwork/e_mod_tw.c| 1 -
15 files changed, 58 insertions(+), 55 deletions(-)
diff --git a/src/bin/e.h b/src/bin/e.h
index 4ecc03c..95d0d8a 100644
--- a/src/bin/e.h
+++ b/src/bin/e.h
@@ -98,6 +98,7 @@ void *alloca (size_t);
# endif
# include
+# include
# include
# include
# include
@@ -116,6 +117,7 @@ void *alloca (size_t);
# include
# include
# include
+# include
# ifdef HAVE_HAL
# include
diff --git a/src/bin/e_config.c b/src/bin/e_config.c
index e08fe03..3ccd865 100644
--- a/src/bin/e_config.c
+++ b/src/bin/e_config.c
@@ -1221,6 +1221,48 @@ e_config_load(void)
break;
}
}
+CONFIG_VERSION_CHECK(13)
+ {
+ E_Config_Theme *et;
+ E_Path_Dir *epd;
+ char buf[PATH_MAX], buf2[PATH_MAX], *f;
+ Eina_List *files;
+ Eina_Bool fail = EINA_FALSE;
+
+ CONFIG_VERSION_UPDATE_INFO(13);
+ // empty out theme elements of config
+ eina_stringshare_del(e_config->init_default_theme);
+ e_config->init_default_theme = NULL;
+ EINA_LIST_FREE(e_config->themes, et)
+ {
+ if (et->category) eina_stringshare_del(et->category);
+ if (et->file) eina_stringshare_del(et->file);
+ E_FREE(et);
+ }
+ EINA_LIST_FREE(e_config->path_append_themes, epd)
+ {
+ if (epd->dir) eina_stringshare_del(epd->dir);
+ E_FREE(epd);
+ }
+ // copy all of ~/.e/e/themes/* into ~/.elementary/themes
+ // and delete original data in ~/.e/e/themes
+ ecore_file_mkpath(elm_theme_user_dir_get());
+ snprintf(buf, sizeof(buf), "%s/themes", e_user_dir_get());
+ files = ecore_file_ls(buf);
+ EINA_LIST_FREE(files, f)
+ {
+ snprintf(buf, sizeof(buf), "%s/themes/%s",
+ e_user_dir_get(), f);
+ snprintf(buf2, sizeof(buf2), "%s/%s",
+ elm_theme_user_dir_get(), f);
+ if (!ecore_file_cp(buf, buf2)) fail = EINA_TRUE;
+ }
+ if (!fail)
+ {
+ snprintf(buf, sizeof(buf), "%s/themes", e_user_dir_get());
+ ecore_file_recursive_rm(buf);
+ }
+ }
}
if (!e_config->remember_internal_fm_windows)
e_config->remember_internal_fm_windows =
!!(e_config->remember_internal_windows & E_REMEMBER_INTERNAL_FM_WINS);
diff --git a/src/bin/e_config.h b/src/bin/e_config.h
index b339be4..9fb334d 100644
--- a/src/bin/e_config.h
+++ b/src/bin/e_config.h
@@ -48,7 +48,7 @@ typedef enum
/* increment this whenever a new set of config values are added but the users
* config doesn't need to be wiped - simply new values need to be put in
*/
-#define E_CONFIG_FILE_GENERATION 12
+#define E_CONFIG_FILE_GENERATION 13
#define E_CONFIG_FILE_VERSION((E_CONFIG_FILE_EPOCH * 100) +
E_CONFIG_FILE_GENERATION)
#define E_CONFIG_BINDINGS_VERSION 0 // DO NOT INCREMENT UNLESS YOU WANT TO
WIPE ALL BINDINGS!!!
Re: [E-devel] Monitor/output parameter for fullscreen
On Fri, 1 Nov 2013 10:16:20 +0900 Cedric BAIL said:
> On Thu, Oct 31, 2013 at 11:58 PM, Rafael Antognolli
> wrote:
> > On Thu, Oct 31, 2013 at 12:50 PM, Carsten Haitzler
> > wrote:
> >> On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL said:
> >>> On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
> >>> wrote:
> >>> > On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler
> >>> > wrote:
> >>> >> On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL
> >>> >> said:
> >>> >>> On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
> >>> >>> wrote:
> >>> >>> > On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
> >>> >>> > wrote:
> >>> >>> >> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
> >>> >>> >> wrote:
> >>> >>> >>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
> >>> >>> >>> wrote:
> >>> >>> Hey everyone,
> >>> >>>
> >>> >>> Our current API for setting a window as fullscreen does not
> >>> >>> support specifying which output/display/monitor should be used
> >>> >>> as fullscreen. However, wayland does support it.
> >>> >>>
> >>> >>> Would it make sense to have such parameter in the fullscreen_set
> >>> >>> API? Or should it be a wayland-only API?
> >>> >>> >>>
> >>> >>> >>> I'd say a new function fullscreen_at_display_set(Display_ID
> >>> >>> >>> *did) /* NULL = unset */
> >>> >>> >>>
> >>> >>> >>> the current version remains and sets on current display.
> >>> >>> >>> Alternatively we could just move the window to another display
> >>> >>> >>> before making that fullscreen, no idea if this is okay.
> >>> >>> >>
> >>> >>> >> Yeah, current version sets on current display (the one where the
> >>> >>> >> non-fullscreen window is already displayed), unless it's the first
> >>> >>> >> time that the window is going to be displayed. Otherwise it will
> >>> >>> >> use the first output. But that's up to the compositor to choose so
> >>> >>> >> far, unless we explicitly specify which output to use.
> >>> >>> >>
> >>> >>> For the latter case, how would we do that? Maybe exposing an API
> >>> >>> that allows to set the "preferred" output, and then when
> >>> >>> fullscreen_set is called, it just uses that one?
> >>> >>> >>>
> >>> >>> >>> I'd say we need to make this in one go, unless we want some kind
> >>> >>> >>> of general assignment to one display (not just for FS mode).
> >>> >>> >>
> >>> >>> >> OK...
> >>> >>> >>
> >>> >>> >>>
> >>> >>> There's also a need to specify how the output should be referred
> >>> >>> to. Using an (unsigned) int, where 0 is the first output, 1 is
> >>> >>> the second, etc? Or maybe allowing to specify something like
> >>> >>> "always the biggest one in area", or the widest one, or
> >>> >>> whatever... any thoughts?
> >>> >>> >>>
> >>> >>> >>> We'd need a way to enumerate the displays (or whatever we call
> >>> >>> >>> them, like zone, etc), they should return their properties such
> >>> >>> >>> as size, position (?), capabilities (3d/stereo? color? what do we
> >>> >>> >>> have here?) and some string to make it easy to debug.
> >>> >>> >>>
> >>> >>> >>> we have the handle to it, so it can be windowsystem agnostic
> >>> >>> >>> (Display_ID *, which can be implemented differently for windows,
> >>> >>> >>> x11, wayland...)
> >>> >>> >>
> >>> >>> >> So you are proposing that we change a good portion of our API to be
> >>> >>> >> aware of multiple displays?
> >>> >>> >>
> >>> >>> >>>
> >>> >>> That reminds me that we still have another problem. APIs such
> >>> >>> ecore_wl_screen_size_get() return only the screen size of the
> >>> >>> first monitor, not both.
> >>> >>> >>>
> >>> >>> >>> same as above, this should be based on current window (if there
> >>> >>> >>> is a window handle) or the first one (if there is not,
> >>> >>> >>> alterntively we can state it will refer to screen the mouse is
> >>> >>> >>> over, but I guess this is incorrect and makes everything less
> >>> >>> >>> predictable).
> >>> >>> >>
> >>> >>> >> Well, that API has no argument, so it just assumes the current
> >>> >>> >> output. For a given window, one could use
> >>> >>> >> ecore_evas_screen_geometry_get, and that indeed will be attached
> >>> >>> >> to a given display, but only after the Ecore_Evas has been shown
> >>> >>> >> first (at least on Wayland, if I'm not wrong).
> >>> >>> >>
> >>> >>> What about a common API to select which output we are talking
> >>> >>> about, that must be called before any call that would refer to a
> >>> >>> specific output? The problem with this is that it would make
> >>> >>> code very wayland-specific :-/
> >>> >>> >>>
> >>> >>> >>> how so? just use the opaque handlers and abstract stuff in there.
> >>> >>> >>
> >>> >>> >> OK, so you suggestion is something like:
> >>> >>> >>
> >>> >>> >> Display {
> >>> >>> >> ID;
> >>> >>> >> size;
> >>> >>> >> position; // might be some info from xrandr, like right-of
> >>> >>> >> another display, etc, if tha
Re: [E-devel] [e-users] Is there *real* documentation for edje?
On Fri, 1 Nov 2013 00:40:42 + Andrew F said: > Hey guys, can someone point me to documentation that explains what a > swallow is? > and how its used. > thanks swallow the name is something i adopted from fvwm2 days - it had swallow stuff... and swallows in edje are the same thing basically - just with objects. didn't you see my link to the swallow docs? https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/lastSuccessfulBuild/artifact/doc/html/group__Edje__Part__Swallow.html#ga97d1419f89bff20ba971e47c78641271 its there in the efl online docs (thats the latest auto nightly doc build). > On Thu, Oct 31, 2013 at 10:22 PM, Andrew F wrote: > > > enlightenment desktop is getting a lot of attention with e17. Good Speed, > > good looks, and great features. > > Maybe its time we step back and look at where we are going and what that > > means. If Enlightenment is going big time, we are going to have more > > qualified programmers join the project and they deserve to have decent > > documentation. After all, why should we make it harder for them to get up > > to speed. If they are joining the project, lets make it as easy as > > possible. > > > > S > > strong > > documentation to strengthen the project. > > P > > erhaps we can brake the information up into logical chapters and have > > different people or teams of people write specific chapters. > > > > Look at QT, they are getting huge and their documentation is exceptional. > > Its easy for developers to get up to speed.Their success is directly > > related to how easy it is to learn to program QT. > > I think we should follow that model to help e17 grow even faster. > > > > We need an editor to outline the document, create the table of contents > > and manage volunteers who will write the individual chapters. > > > > Who has the knowledge of e17 to do this? > > > > > > On Thu, Oct 31, 2013 at 2:49 PM, Carsten Haitzler > > wrote: > > > >> On Thu, 31 Oct 2013 09:02:04 -0300 Vinícius dos Santos Oliveira > >> said: > >> > >> > Em Qui, 2013-10-31 às 08:51 +0900, Carsten Haitzler escreveu: > >> > > >> > > i know. i spent some of my early life on unix/linux paying large sums > >> > > for > >> > > o'reilly books. and reading them cover to cover. they had diagrams. i > >> > > frankly > >> > > far prefer raw simple code over those books. the code is digestible in > >> > > a > >> > > fraction of the time. :) if i have an actual working bit of code i can > >> > > compile > >> > > it, run it and then modify it to see how it wobbles when poked. poke a > >> > > bit more > >> > > and see some more wobbling. these wobbles tell me the story of how > >> > > CHANGES to > >> > > the example affect the behaviour. start small with small changes and > >> > > see. :) a > >> > > book doesn't give me that. english words don't give me that. code > >> > > does. :) but > >> > > that is my style - i know that within all fields of education > >> > > including foreign > >> > > languages, math, science, etc. etc. i always gravitated to "learn by > >> > > example". > >> > > i naturally break up the examples into their constituent parts and > >> > > know how to > >> > > manipulate them - the pattern builds over time naturally. > >> > > >> > > >> > Code is interactive. School and all non-interactive shit is difficult > >> > and pain to learn (at least for me and for you). > >> > > >> > But... I wonder how you avoid undefined behaviour code that can break in > >> > the next release of the lib/compiler or in the second compiler/platform. > >> > >> experience teaches... and of course reading docs/references. > >> > >> -- > >> - Codito, ergo sum - "I code, therefore I am" -- > >> The Rasterman (Carsten Haitzler)ras...@rasterman.com > >> > >> > >> > >> -- > >> Android is increasing in popularity, but the open development platform > >> that > >> developers love is also attractive to malware creators. Download this > >> white > >> paper to learn more about secure code signing practices that can help keep > >> Android apps secure. > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > -- > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lis
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
On Fri, 1 Nov 2013 10:06:40 +0900 Cedric BAIL said:
> Hello,
>
> On Fri, Nov 1, 2013 at 5:45 AM, Bertrand Jacquin wrote:
> > Here is the list of last *git write* access from enable users with that
> > some ugly script :
> >
> > getent passwd \
> >| awk -F : '
> >{
> > if ($3 >= 1000 && $3 <= && $7 != "/sbin/nologin") {
> >print $1
> > }
> >}' \
> >| while read ; do
> >awk -v REPLY="${REPLY}" -v LAST=never '
> > {
> >if ($2 == REPLY && $4 = "git-receive-pack") {
> > LAST=$1
> >}
> > }
> >
> > END {
> >print REPLY,LAST
> > }' /var/log/gitolite/gitolite-*.log
> > done \
> >| sort -k 2 | column -t
> >
> > acidx never
> > aron never
> > ceolin never
> > dresb never
> > ewww never
> > fidencio never
> > gouachenever
> > incnever
> > kakaroto never
> > mello never
> > mickeylnever
> > monkeyiq never
> > morlenxus never
> > nash never
> > pespin never
> > playya never
> > raoul never
> > rfonseca never
> > ruinever
> > shorne never
> > sohyun never
> > turran never
> > vapier never
> > watchwolf never
> > xhell never
> > mej2013-03-25.09:48:07
> > andreas2013-05-18.04:52:14
> > gastal 2013-06-06.11:50:36
> > rakuco 2013-06-26.06:26:52
> > mekius 2013-07-08.17:22:09
> > thanatermesis 2013-08-02.06:32:06
> > tiago 2013-08-23.12:20:41
> > bdilly 2013-09-02.14:30:44
> > garik 2013-09-03.17:11:56
> > kimcinoo 2013-09-10.17:57:03
> > jypark 2013-09-12.01:43:39
> > jeffdameth 2013-10-02.14:26:17
> > princeamd 2013-10-03.05:35:25
> > mike_m 2013-10-06.15:02:43
> > quaker 2013-10-07.09:16:59
> > dorileo2013-10-15.13:29:13
> > asdfuser 2013-10-16.00:05:44
> > jaehwan2013-10-17.04:00:28
> > sanjeev2013-10-17.05:59:19
> > okra 2013-10-17.10:10:06
> > jihoon 2013-10-17.18:23:00
> > glima 2013-10-18.13:29:26
> > kiwi 2013-10-18.19:17:07
> > captainigloo 2013-10-18.21:54:23
> > kwo2013-10-19.10:36:26
> > billiob2013-10-20.03:45:11
> > illogict 2013-10-21.10:46:34
> > demarchi 2013-10-24.14:38:48
> > beber 2013-10-25.02:04:52
> > etrunko2013-10-25.18:36:25
> > stefan 2013-10-26.03:14:42
> > maxerba2013-10-26.03:41:45
> > onefang2013-10-26.08:22:49
> > jackdanielz2013-10-27.01:09:45
> > davemds2013-10-28.15:51:17
> > ravenlock 2013-10-28.18:54:29
> > ngc891 2013-10-29.03:30:26
> > hyoyoung 2013-10-29.07:55:17
> > zehortigoza2013-10-29.11:17:11
> > barbieri 2013-10-29.15:43:12
> > sung 2013-10-29.23:27:57
> > yakov 2013-10-30.02:52:25
> > ulisses2013-10-30.07:35:56
> > sachiel2013-10-30.11:02:33
> > kuuko 2013-10-30.12:02:57
> > discomfitor2013-10-30.14:25:55
> > yoz2013-10-30.17:04:55
> > jpeg 2013-10-30.18:12:46
> > englebass 2013-10-31.00:17:03
> > woohyun2013-10-31.00:51:09
> > hermet 2013-10-31.01:04:25
> > leif 2013-10-31.02:50:45
> > ryuan 2013-10-31.05:43:18
> > cedric 2013-10-31.06:21:22
> > seoz 2013-10-31.07:02:33
> > antognolli 2013-10-31.07:09:28
> > urandom2013-10-31.07:49:43
> > tasn 2013-10-31.09:05:23
> > devilhorns 2013-10-31.10:22:47
> > raster 2013-10-31.11:03:46
> > jeyzu 2013-10-31.11:13:21
> > uartie 2013-10-31.11:45:41
> > kuri 2013-10-31.13:08:38
>
> Thanks for the list. I would just argue that we have moved to git less
> than a year ago. So maybe we should go over that list again for the
> one year anniversary of our move to git.
i think that is sensible. and that would make it after we get out efl
1.8/e18 ... which was kind of what i thought of to begin with. :) let git be
alive and kicking for at least a year before we use its stats to remove
access. :)
unless we literally are seeing security breaches and issues with dead/inactive
users... i don't think there is a big risk in waiting. :)
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
[EGIT] [core/efl] master 06/07: edje: make functions "edje_edit_state_fill/aspect/align..." return Eina_Bool
cedric pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=6f8b1c1b02e4b59da437e40acd2f3434e78d1c7a commit 6f8b1c1b02e4b59da437e40acd2f3434e78d1c7a Author: m.biliavskyi Date: Fri Nov 1 11:17:24 2013 +0900 edje: make functions "edje_edit_state_fill/aspect/align..." return Eina_Bool Make the following function return Eina_Bool so the caller can detect errors : List of updated functions: edje_edit_state_align_x_set edje_edit_state_align_y_set edje_edit_state_aspect_min_set edje_edit_state_aspect_max_set edje_edit_state_aspect_pref_set edje_edit_state_fill_origin_relative_x_set edje_edit_state_fill_origin_relative_y_set edje_edit_state_fill_origin_offset_x_set edje_edit_state_fill_origin_offset_y_set edje_edit_state_fill_size_relative_x_set edje_edit_state_fill_size_relative_y_set edje_edit_state_fill_size_offset_x_set edje_edit_state_fill_size_offset_y_set Reviewers: cedric, seoz Reviewed By: cedric CC: reutskiy.v.v Differential Revision: https://phab.enlightenment.org/D300 Signed-off-by: Cedric Bail --- src/lib/edje/Edje_Edit.h | 52 src/lib/edje/edje_edit.c | 33 -- 2 files changed, 57 insertions(+), 28 deletions(-) diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h index 10ad69f..2a2f5e1 100644 --- a/src/lib/edje/Edje_Edit.h +++ b/src/lib/edje/Edje_Edit.h @@ -1648,8 +1648,10 @@ EAPI double edje_edit_state_align_y_get(Evas_Object *obj, const char *part, cons * @param state The name of the state to get horizontal align (not including the state value). * @param value The state value. * @param align The new vertical align value. + * + * @return EINA_TRUE if the parameter was found, EINA_FALSE otherwise. */ -EAPI void edje_edit_state_align_x_set(Evas_Object *obj, const char *part, const char *state, double value, double align); +EAPI Eina_Bool edje_edit_state_align_x_set(Evas_Object *obj, const char *part, const char *state, double value, double align); /** Set the vertical align value of a part state. * @@ -1658,8 +1660,10 @@ EAPI void edje_edit_state_align_x_set(Evas_Object *obj, const char *part, const * @param state The name of the state to get vertical align (not including the state value). * @param value The state value. * @param align The new vertical align value. + * + * @return EINA_TRUE if the parameter was found, EINA_FALSE otherwise. */ -EAPI void edje_edit_state_align_y_set(Evas_Object *obj, const char *part, const char *state, double value, double align); +EAPI Eina_Bool edje_edit_state_align_y_set(Evas_Object *obj, const char *part, const char *state, double value, double align); /** Get the minimum width value of a part state. * @@ -1790,8 +1794,10 @@ EAPI double edje_edit_state_aspect_max_get(Evas_Object *obj, const char *part, c * @param state The name of the state to set minimum aspect (not including the state value). * @param value The state value. * @param aspect Minimum aspect value. + * + * @return EINA_TRUE if the parameter was found, EINA_FALSE otherwise. */ -EAPI void edje_edit_state_aspect_min_set(Evas_Object *obj, const char *part, const char *state, double value, double aspect); +EAPI Eina_Bool edje_edit_state_aspect_min_set(Evas_Object *obj, const char *part, const char *state, double value, double aspect); /** Set the maximum aspect value of a part state. * @@ -1800,8 +1806,10 @@ EAPI void edje_edit_state_aspect_min_set(Evas_Object *obj, const char *part, con * @param state The name of the state to set maximum aspect (not including the state value). * @param value The state value. * @param aspect Maximum aspect value. + * + * @return EINA_TRUE if the parameter was found, EINA_FALSE otherwise. */ -EAPI void edje_edit_state_aspect_max_set(Evas_Object *obj, const char *part, const char *state, double value, double aspect); +EAPI Eina_Bool edje_edit_state_aspect_max_set(Evas_Object *obj, const char *part, const char *state, double value, double aspect); /** Get the aspect preference of a part state. * @@ -1823,8 +1831,10 @@ EAPI unsigned char edje_edit_state_aspect_pref_get(Evas_Object *obj, const char * @param value The state value. * @param pref The aspect preference to set (0 = None, 1 = Vertical, 2 * = Horizontal, 3 = Both) + * + * @return EINA_TRUE if the parameter was found, EINA_FALSE otherwise. */ -EAPI void edje_edit_state_aspect_pref_set(Evas_Object *obj, const char *part, const char *state, double value, unsigned char pref); +EAPI Eina_Bool edje_edit_state_aspect_pref_set(Evas_Object *obj, const char *part, const char *state, double value, unsigned char pref); /** Get the fill horizontal origin relative value of a part state. * @@ -1877,8 +1887,10 @@ EAPI int edje_edit_state_fill_origin_offset_y_get(Evas_Object *obj, const char *
[EGIT] [core/efl] master 05/07: ChangeLog: let's try to be more informative in our commit.
cedric pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=cba1fa5dd525b72504ac7530454a71267b853e70 commit cba1fa5dd525b72504ac7530454a71267b853e70 Author: Cedric Bail Date: Fri Nov 1 11:15:35 2013 +0900 ChangeLog: let's try to be more informative in our commit. Would be good that everyone specify on which part there change did apply. Some are really not obvious. --- ChangeLog | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/ChangeLog b/ChangeLog index 9114991..4f7ad02 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,5 @@ 2013-10-24 Sung W. Park (sung_) + * EvasGL: Fixed direct rendering mode not clipping to its clip region. 2013-10-24 Youngbok Shin @@ -7,27 +8,27 @@ 2013-10-18 Youngbok Shin -* Fixed the textblock format to be drawn according to -the glyph's horizontal advance width. +* Evas: Fixed the textblock format to be drawn according to the glyph's + horizontal advance width. 2013-10-15 ChunEon Park (Hermet) -* Fixed the map surface to be updated properly. By tranversing the +* Evas: Fixed the map surface to be updated properly. By tranversing the whole of the map target's tree, it decides to update the map surface to be redrawn if one of the objects is changed except the clipper itself. 2013-10-15 ChunEon Park (Hermet) -* Fixed memory leak in the edje map color transition. +* Edje: Fixed memory leak in the edje map color transition. 2013-10-11 Carsten Haitzler (The Rasterman) -* deprecate/remove all the eina_error setting (and getting) +* Eina: deprecate/remove all the eina_error setting (and getting) within efl no one uses it and it frankly it much more pain than it's worth. the api's are still there, and efl api's still fail as they did before.. they just don't ALSO set eina_error. - + 2013-10-11 Cedric Bail * Eina: add Eina_Spinlock API, @@ -433,11 +434,11 @@ 2013-05-20 Carsten Haitzler (The Rasterman) -* Improve memory footpriny by only creating evasgl context on demand. +* Evas: Improve memory footpriny by only creating evasgl context on demand. 2013-05-18 Carsten Haitzler (The Rasterman) -* Reduce waiting on gl so it cvan fully run async from cpu. +* Evas: Reduce waiting on gl so it cvan fully run async from cpu. 2013-05-16 Tom Hacohen --
[EGIT] [core/efl] master 03/07: edje: make functions return Eina_Bool and fix documentation.
cedric pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=3973ecf2e80b0546bcd26cc7a56b6719f0263fee commit 3973ecf2e80b0546bcd26cc7a56b6719f0263fee Author: Andrii Kroitor Date: Fri Nov 1 11:03:30 2013 +0900 edje: make functions return Eina_Bool and fix documentation. Make the following functions return Eina_Bool so the caller can detect errors: edje_edit_part_drag_x_set edje_edit_part_drag_y_set edje_edit_part_drag_step_x_set edje_edit_part_drag_step_y_set edje_edit_part_drag_count_x_set edje_edit_part_drag_count_y_set Added functions for threshold: edje_edit_part_drag_threshold_set edje_edit_part_drag_threshold_get Fixed description of 'count' parameter of dragable.x/y Reviewers: cedric, seoz Reviewed By: cedric CC: reutskiy.v.v Differential Revision: https://phab.enlightenment.org/D304 Signed-off-by: Cedric Bail --- src/bin/edje/edje_cc_handlers.c | 6 +++-- src/lib/edje/Edje_Edit.h| 43 ++- src/lib/edje/edje_edit.c| 56 - 3 files changed, 69 insertions(+), 36 deletions(-) diff --git a/src/bin/edje/edje_cc_handlers.c b/src/bin/edje/edje_cc_handlers.c index 0c1e5ca..76cf7e1 100644 --- a/src/bin/edje/edje_cc_handlers.c +++ b/src/bin/edje/edje_cc_handlers.c @@ -4369,7 +4369,8 @@ st_collections_group_parts_part_access(void) enabled, 1 will set the starting point at 0.0 and -1 at 1.0. The second parameter takes any integer and will limit movement to values divisible by it, causing the part to jump from position to position. -The third parameter, (question from the author: What is count for?). +If step is set to 0 it is calculated as width of confine part divided by +count. @endproperty */ static void @@ -4394,7 +4395,8 @@ st_collections_group_parts_part_dragable_x(void) enabled, 1 will set the starting point at 0.0 and -1 at 1.0. The second parameter takes any integer and will limit movement to values divisibles by it, causing the part to jump from position to position. -The third parameter, (question from the author: What is count for?). +If step is set to 0 it is calculated as height of confine part divided by +count. @endproperty */ static void diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h index ab7bda6..10ad69f 100644 --- a/src/lib/edje/Edje_Edit.h +++ b/src/lib/edje/Edje_Edit.h @@ -1026,8 +1026,10 @@ EAPI int edje_edit_part_drag_x_get(Evas_Object *obj, const char *part); * @param obj Object being edited. * @param part Part to set if should be dragged horizontally. * @param drag 1 (or -1) if the part should be dragged horizontally, 0 otherwise. + * + * @return EINA_TRUE if successful, EINA_FALSE otherwise. */ -EAPI void edje_edit_part_drag_x_set(Evas_Object *obj, const char *part, int drag); +EAPI Eina_Bool edje_edit_part_drag_x_set(Evas_Object *obj, const char *part, int drag); /** Get vertical dragable state for part. * @@ -1043,8 +1045,10 @@ EAPI int edje_edit_part_drag_y_get(Evas_Object *obj, const char *part); * @param obj Object being edited. * @param part Part to set if should be dragged vertically. * @param drag 1 (or -1) of the part shpuld be dragged vertically, 0 otherwise. + * + * @return EINA_TRUE if successful, EINA_FALSE otherwise. */ -EAPI void edje_edit_part_drag_y_set(Evas_Object *obj, const char *part, int drag); +EAPI Eina_Bool edje_edit_part_drag_y_set(Evas_Object *obj, const char *part, int drag); /** Get horizontal dragable step for part. * @@ -1060,8 +1064,10 @@ EAPI int edje_edit_part_drag_step_x_get(Evas_Object *obj, const char *part); * @param obj Object being edited. * @param part Part to set the drag horizontal step value. * @param step The step the will be dragged. + * + * @return EINA_TRUE if successful, EINA_FALSE otherwise. */ -EAPI void edje_edit_part_drag_step_x_set(Evas_Object *obj, const char *part, int step); +EAPI Eina_Bool edje_edit_part_drag_step_x_set(Evas_Object *obj, const char *part, int step); /** Get vertical dragable step for part. * @@ -1077,8 +1083,10 @@ EAPI int edje_edit_part_drag_step_y_get(Evas_Object *obj, const char *part); * @param obj Object being edited. * @param part Part to set the drag vertical step value. * @param step The step the will be dragged. + * + * @return EINA_TRUE if successful, EINA_FALSE otherwise. */ -EAPI void edje_edit_part_drag_step_y_set(Evas_Object *obj, const char *part, int step); +EAPI Eina_Bool edje_edit_part_drag_step_y_set(Evas_Object *obj, const char *part, int step); /** Get horizontal dragable count for part. * @@ -1092,8 +1100,10 @@ EAPI int edje_edit_part_drag_count_x_get(Evas_Object *obj, const char *part); * @param obj Object being edited. * @param part Part to set the drag hor
[EGIT] [core/efl] master 01/07: edje: make it possible for all upper layer function to query the exact same file.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=cf452cc419b5c4449d0538a9638f79b898f10025
commit cf452cc419b5c4449d0538a9638f79b898f10025
Author: Cedric Bail
Date: Fri Nov 1 10:58:33 2013 +0900
edje: make it possible for all upper layer function to query the exact same
file.
With Eina_File we now can pass an efficient handler accross library
boundary. Edje
and all underlayer already use it to avoid race condition when setting an
Edje object.
Elementary and Enlightenment are still exposed to some potential race
condition when
an Edje file is modified underneath there feet. With the following set of
function it
should now be possible to avoid those race condition to:
edje_mmap_data_get
edje_mmap_collection_list
edje_mmap_collection_list_free
edje_mmap_group_exists
---
src/lib/edje/Edje_Common.h | 53
src/lib/edje/edje_load.c | 100 +++--
2 files changed, 123 insertions(+), 30 deletions(-)
diff --git a/src/lib/edje/Edje_Common.h b/src/lib/edje/Edje_Common.h
index 8e72b75..dc5a01d 100644
--- a/src/lib/edje/Edje_Common.h
+++ b/src/lib/edje/Edje_Common.h
@@ -119,6 +119,25 @@ EAPI int edje_shutdown (void);
EAPI void edje_fontset_append_set (const char *fonts);
/**
+ * Get data from the file level data block of an edje mapped file
+ * @param file The mapped edje file
+ * @param key The data key
+ * @return The string value of the data or NULL if no key is found.
+ * Must be freed by the user when no longer needed.
+ *
+ * If an edje file test.edj is built from the following edc:
+ *
+ * data {
+ * item: "key1" "value1";
+ * item: "key2" "value2";
+ * }
+ * collections { ... }
+ *
+ * Then, edje_file_data_get("test.edj", "key1") will return "value1"
+ */
+EAPI char *edje_mmap_data_get(Eina_File *f, const char *key);
+
+/**
* Get data from the file level data block of an edje file
* @param file The path to the .edj file
* @param key The data key
@@ -134,6 +153,8 @@ EAPI void edje_fontset_append_set (const
char *fonts);
* collections { ... }
*
* Then, edje_file_data_get("test.edj", "key1") will return "value1"
+ *
+ * @see edje_mmap_data_get()
*/
EAPI char*edje_file_data_get (const char *file, const
char *key);
@@ -1553,14 +1574,46 @@ typedef enum _Edje_Load_Error
EDJE_LOAD_ERROR_RECURSIVE_REFERENCE = 9 /**< The group/collection set to
load from had recursive references on its components */
} Edje_Load_Error; /**< Edje file loading error codes one can get - see
edje_load_error_str() too. */
+
+/**
+ * Get a list of groups in an edje mapped file
+ * @param file The mapped file
+ *
+ * @return The Eina_List of group names (char *)
+ *
+ * Note: the list must be freed using edje_mmap_collection_list_free()
+ * when you are done with it.
+ */
+EAPI Eina_List*edje_mmap_collection_list(Eina_File *f);
+
+/**
+ * Free file collection list
+ * @param lst The Eina_List of groups
+ *
+ * Frees the list returned by edje_mmap_collection_list().
+ */
+EAPI void edje_mmap_collection_list_free(Eina_List *lst);
+
+/**
+ * Determine whether a group matching glob exists in an edje mapped file.
+ * @param file The mapped file
+ * @param glob A glob to match on
+ *
+ * @return 1 if a match is found, 0 otherwise
+ */
+EAPI Eina_Bool edje_mmap_group_exists(Eina_File *f, const char *glob);
+
/**
* Get a list of groups in an edje file
* @param file The path to the edje file
*
* @return The Eina_List of group names (char *)
+ * @see edje_mmap_collection_list()
*
* Note: the list must be freed using edje_file_collection_list_free()
* when you are done with it.
+ *
+ * @see edje_mmap_group_exists()
*/
EAPI Eina_List*edje_file_collection_list (const char *file);
diff --git a/src/lib/edje/edje_load.c b/src/lib/edje/edje_load.c
index f69b59e..d78fa68 100644
--- a/src/lib/edje/edje_load.c
+++ b/src/lib/edje/edje_load.c
@@ -156,17 +156,13 @@ edje_load_error_str(Edje_Load_Error error)
}
}
-
EAPI Eina_List *
-edje_file_collection_list(const char *file)
+edje_mmap_collection_list(Eina_File *f)
{
Eina_List *lst = NULL;
- Eina_File *f;
Edje_File *edf;
int error_ret = 0;
-
- if ((!file) || (!*file)) return NULL;
- f = eina_file_open(file, EINA_FALSE);
+
if (!f) return NULL;
edf = _edje_cache_file_coll_open(f, NULL, &error_ret, NULL, NULL);
if (edf)
@@ -183,6 +179,21 @@ edje_file_collection_list(const char *file)
_edje_cache_file_unref(edf);
}
+
+ return lst;
+}
+
+EAPI Eina_List *
+edje_file_collection_list(const char *file)
+{
+ Eina_File *f;
+ Eina_List *lst;
+
+ if ((!file) || (!*file)) return NULL;
+ f = eina_file_open(file, EINA_FALSE);
+
+ lst = edje_mmap_collection_list(f);
+
eina_file_clo
[EGIT] [core/efl] master 02/07: edje: make functions in edje_edit API return Eina_Bool.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=848cc1d1ea1fc99bf5c8181a6735a414c178076f
commit 848cc1d1ea1fc99bf5c8181a6735a414c178076f
Author: Vorobiov Vitalii
Date: Fri Nov 1 11:01:37 2013 +0900
edje: make functions in edje_edit API return Eina_Bool.
Make the following functions return Eina_Bool so the caller can detect
errors:
edje_edit_state_visible_set
edje_edit_state_color_class_set
Removed unnecessary check in edje_edit_state_image_border_fill_set.
Reviewers: cedric, seoz
Reviewed By: cedric
CC: reutskiy.v.v
Differential Revision: https://phab.enlightenment.org/D305
Signed-off-by: Cedric Bail
---
src/lib/edje/Edje_Edit.h | 8 ++--
src/lib/edje/edje_edit.c | 24
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 77dfff9..ab7bda6 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -1987,8 +1987,10 @@ EAPI Eina_Bool edje_edit_state_visible_get(Evas_Object
*obj, const char *part, c
* @param state The name of the state to set visibility (not including the
state value).
* @param value The state value.
* @param visible To set state visible (EINA_TRUE if the state is visible,
EINA_FALSE otherwise)
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
*/
-EAPI void edje_edit_state_visible_set(Evas_Object *obj, const char *part,
const char *state, double value, Eina_Bool visible);
+EAPI Eina_Bool edje_edit_state_visible_set(Evas_Object *obj, const char *part,
const char *state, double value, Eina_Bool visible);
/** Get the color class of the given part state.
*
@@ -2010,8 +2012,10 @@ EAPI const char
*edje_edit_state_color_class_get(Evas_Object *obj, const char *p
* @param state The name of the state to set color class (not including the
state value).
* @param value The state value.
* @param color_class The color class to assign.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
*/
-EAPI void edje_edit_state_color_class_set(Evas_Object *obj, const char *part,
const char *state, double value, const char *color_class);
+EAPI Eina_Bool edje_edit_state_color_class_set(Evas_Object *obj, const char
*part, const char *state, double value, const char *color_class);
/** Get the list of parameters for an external part.
*
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index 34dfb45..2699604 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -3533,14 +3533,18 @@ edje_edit_state_visible_get(Evas_Object *obj, const
char *part, const char *stat
return pd->visible;
}
-EAPI void
+EAPI Eina_Bool
edje_edit_state_visible_set(Evas_Object *obj, const char *part, const char
*state, double value, Eina_Bool visible)
{
- GET_PD_OR_RETURN();
- //printf("Set state visible flag of part: %s state: %s to: %d\n", part,
state, visible);
+ if ((!obj) || (!part) || (!state))
+ return EINA_FALSE;
+ GET_PD_OR_RETURN(EINA_FALSE);
+
if (visible) pd->visible = 1;
else pd->visible = 0;
+
edje_object_calc_force(obj);
+ return EINA_TRUE;
}
EAPI unsigned char
@@ -3569,13 +3573,17 @@ edje_edit_state_color_class_get(Evas_Object *obj, const
char *part, const char *
return eina_stringshare_add(pd->color_class);
}
-EAPI void
+EAPI Eina_Bool
edje_edit_state_color_class_set(Evas_Object *obj, const char *part, const char
*state, double value, const char *color_class)
{
- GET_PD_OR_RETURN();
- //printf("Set ColorClass of part: %s state: %s [to: %s]\n", part, state,
color_class);
+ if ((!obj) || (!part) || (!state))
+ return EINA_FALSE;
+ GET_PD_OR_RETURN(EINA_FALSE);
+
_edje_if_string_free(ed, pd->color_class);
- pd->color_class = (char*)eina_stringshare_add(color_class);
+
+ pd->color_class = (char *)eina_stringshare_add(color_class);
+ return EINA_TRUE;
}
EAPI const Eina_List *
@@ -4798,7 +4806,7 @@ edje_edit_state_image_border_fill_set(Evas_Object *obj,
const char *part, const
if ((!obj) || (!part) || (!state))
return EINA_FALSE;
- if ((fill < 0) || (fill > 2))
+ if (fill > 2)
return EINA_FALSE;
eina_error_set(0);
--
[EGIT] [core/efl] master 04/07: Evas: Fixed textblock rendering to properly set render operation on context.
cedric pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=cdb86e34bbf82bd91aefd686bfc3bdf2a018a956 commit cdb86e34bbf82bd91aefd686bfc3bdf2a018a956 Author: Youngbok Shin Date: Fri Nov 1 11:09:58 2013 +0900 Evas: Fixed textblock rendering to properly set render operation on context. Render operation are not well tested. It appears that it was never properly setted on a textblock, this would lead to see it rendered with the render operation of another object. Test Plan: Add some rectangle object with textblock object. The textblock style should be set to "backing=on backing_color=#". Set render operation to some rectangle with "evas_object_render_op_set(rect, EVAS_RENDER_COPY)". Check the textblock. Reviewers: woohyun, cedric, raster Reviewed By: cedric CC: cedric Differential Revision: https://phab.enlightenment.org/D277 Signed-off-by: Cedric Bail --- ChangeLog | 4 NEWS| 1 + src/lib/evas/canvas/evas_object_textblock.c | 1 + 3 files changed, 6 insertions(+) diff --git a/ChangeLog b/ChangeLog index c5042ad..9114991 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,6 +1,10 @@ 2013-10-24 Sung W. Park (sung_) * EvasGL: Fixed direct rendering mode not clipping to its clip region. +2013-10-24 Youngbok Shin + +* Evas: Fix textblock rendering to properly set render operation on the context. + 2013-10-18 Youngbok Shin * Fixed the textblock format to be drawn according to diff --git a/NEWS b/NEWS index 99ca54a..2b4f923 100644 --- a/NEWS +++ b/NEWS @@ -358,6 +358,7 @@ Fixes: - Evas textblock: fixed an issue with markup_get and markup_to_utf8 behaving differently (markup_get was misbehaving). - Fixed the map surface to be updated properly. By tranversing the whole of the map target's tree, it decides to update the map surface to be redrawn if one of the objects is changed except the clipper itself. - Fixed the textblock format to be drawn according to the glyph's horizontal advance width. + - Fixed the textblock set to context with the textblock object's render operation. * Ecore: - Don't leak fd on exec. diff --git a/src/lib/evas/canvas/evas_object_textblock.c b/src/lib/evas/canvas/evas_object_textblock.c index 0566f93..0c01a86 100644 --- a/src/lib/evas/canvas/evas_object_textblock.c +++ b/src/lib/evas/canvas/evas_object_textblock.c @@ -10726,6 +10726,7 @@ evas_object_textblock_render(Evas_Object *eo_obj EINA_UNUSED, /* render object to surface with context, and offxet by x,y */ obj->layer->evas->engine.func->context_multiplier_unset(output, context); + ENFN->context_render_op_set(output, context, obj->cur->render_op); /* FIXME: This clipping is just until we fix inset handling correctly. */ ENFN->context_clip_clip(output, context, obj->cur->geometry.x + x, --
[EGIT] [core/efl] master 07/07: edje: make mouse_events, repeat_events, ignore_flags and scale setters return Eina_Bool.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=d00721a3d79699637e935472d6e80f21ec055c73
commit d00721a3d79699637e935472d6e80f21ec055c73
Author: Andrii Kroitor
Date: Fri Nov 1 11:30:23 2013 +0900
edje: make mouse_events, repeat_events, ignore_flags and scale setters
return Eina_Bool.
Make the following function return Eina_Bool so the caller can detect
errors :
edje_edit_part_mouse_events_set
edje_edit_part_repeat_events_set
edje_edit_part_ignore_flags_set
edje_edit_part_scale_set
Reviewers: cedric, seoz
Reviewed By: cedric
CC: reutskiy.v.v
Differential Revision: https://phab.enlightenment.org/D303
Signed-off-by: Cedric Bail
---
src/lib/edje/Edje_Edit.h | 22 +++---
src/lib/edje/edje_edit.c | 45 +
2 files changed, 36 insertions(+), 31 deletions(-)
diff --git a/src/lib/edje/Edje_Edit.h b/src/lib/edje/Edje_Edit.h
index 2a2f5e1..917dd79 100644
--- a/src/lib/edje/Edje_Edit.h
+++ b/src/lib/edje/Edje_Edit.h
@@ -946,7 +946,7 @@ EAPI Eina_Bool
edje_edit_part_selected_state_set(Evas_Object *obj, const char *p
* @param obj Object being edited.
* @param part Part to get if the mouse events is accepted.
*
- * @return EINA_TRUE if successful, EINA_FALSE otherwise.
+ * @return EINA_TRUE if part will accept mouse events, EINA_FALSE otherwise.
*/
EAPI Eina_Bool edje_edit_part_mouse_events_get(Evas_Object *obj, const char
*part);
@@ -955,15 +955,17 @@ EAPI Eina_Bool
edje_edit_part_mouse_events_get(Evas_Object *obj, const char *par
* @param obj Object being edited.
* @param part The part to set if the mouse events is accepted.
* @param mouse_events EINA_TRUE if part will accept mouse events, EINA_FALSE
otherwise.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
*/
-EAPI void edje_edit_part_mouse_events_set(Evas_Object *obj, const char *part,
Eina_Bool mouse_events);
+EAPI Eina_Bool edje_edit_part_mouse_events_set(Evas_Object *obj, const char
*part, Eina_Bool mouse_events);
/** Get repeat_events for part.
*
* @param obj Object being edited.
- * @param part Part to set if will pass all events to the other parts.
+ * @param part Part to get if it will pass all events to the other parts.
*
- * @return EINA_TRUE if successful, EINA_FALSE otherwise.
+ * @return EINA_TRUE if the events received will propagate to other parts,
EINA_FALSE otherwise
*/
EAPI Eina_Bool edje_edit_part_repeat_events_get(Evas_Object *obj, const char
*part);
@@ -972,8 +974,10 @@ EAPI Eina_Bool
edje_edit_part_repeat_events_get(Evas_Object *obj, const char *pa
* @param obj Object being edited.
* @param part Part to set if will repeat all the received mouse events to
other parts.
* @param repeat_events EINA_TRUE if the events received will propagate to
other parts, EINA_FALSE otherwise
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
*/
-EAPI void edje_edit_part_repeat_events_set(Evas_Object *obj, const char *part,
Eina_Bool repeat_events);
+EAPI Eina_Bool edje_edit_part_repeat_events_set(Evas_Object *obj, const char
*part, Eina_Bool repeat_events);
/** Get ignore_flags for part.
*
@@ -989,8 +993,10 @@ EAPI Evas_Event_Flags
edje_edit_part_ignore_flags_get(Evas_Object *obj, const ch
* @param obj Object being edited.
* @param part Part to set which event flags will be ignored.
* @param ignore_flags The Event flags to be ignored by the part.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
*/
-EAPI void edje_edit_part_ignore_flags_set(Evas_Object *obj, const char *part,
Evas_Event_Flags ignore_flags);
+EAPI Eina_Bool edje_edit_part_ignore_flags_set(Evas_Object *obj, const char
*part, Evas_Event_Flags ignore_flags);
/** Set scale property for the part.
*
@@ -1000,8 +1006,10 @@ EAPI void edje_edit_part_ignore_flags_set(Evas_Object
*obj, const char *part, Ev
* @param obj Object being edited.
* @param part Part to set scale for.
* @param scale Scale value to set.
+ *
+ * @return EINA_TRUE if successful, EINA_FALSE otherwise.
*/
-EAPI void edje_edit_part_scale_set(Evas_Object *obj, const char *part,
Eina_Bool scale);
+EAPI Eina_Bool edje_edit_part_scale_set(Evas_Object *obj, const char *part,
Eina_Bool scale);
/** Get scale for the part.
*
diff --git a/src/lib/edje/edje_edit.c b/src/lib/edje/edje_edit.c
index d75b55f..038414d 100644
--- a/src/lib/edje/edje_edit.c
+++ b/src/lib/edje/edje_edit.c
@@ -2371,50 +2371,44 @@ EAPI Eina_Bool
edje_edit_part_mouse_events_get(Evas_Object *obj, const char *part)
{
GET_RP_OR_RETURN(EINA_FALSE);
- //printf("Get mouse_events for part: %s [%d]\n", part,
rp->part->mouse_events);
return rp->part->mouse_events;
}
-EAPI void
+EAPI Eina_Bool
edje_edit_part_mouse_events_set(Evas_Object *obj, const char *part, Eina_Bool
mouse_events)
{
- GET_RP_OR_RETURN();
-
- if (!rp->object) return;
+ GET_RP_OR_R
Re: [E-devel] [EGIT] [core/efl] master 01/03: Stop leaking evas objects in Lua.
On Wed, 30 Oct 2013 11:44:33 +0100 Leif Middelschulte wrote: > Unfortunately, this bug is still valid. > Applications using lua crash, if it creates(/deletes) sufficient > elements. See https://phab.enlightenment.org/T323 for an example that > will crash e.g. edje_player if the window is resized a couple of > times. > > Could you have another look? I guess that increasing the number of > rects should crash the applications right on startup. I'll see if I can look into it on the weekend. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/elementary] master 01/01: add @since 1.8 for new elm theme api's
raster pushed a commit to branch master. http://git.enlightenment.org/core/elementary.git/commit/?id=1cab45a47b6a3de31d5fcf24101c23eed5fb593a commit 1cab45a47b6a3de31d5fcf24101c23eed5fb593a Author: Carsten Haitzler (Rasterman) Date: Fri Nov 1 10:56:02 2013 +0900 add @since 1.8 for new elm theme api's --- src/lib/elm_theme.h | 4 1 file changed, 4 insertions(+) diff --git a/src/lib/elm_theme.h b/src/lib/elm_theme.h index 268dd6f..b4467d9 100644 --- a/src/lib/elm_theme.h +++ b/src/lib/elm_theme.h @@ -450,6 +450,7 @@ EAPI const char *elm_theme_data_get(Elm_Theme *th, const char *key); * If group is NULL, then nothing can be looked up, so it is a non-sensical * request. * + * @since 1.8 * @ingroup Theme */ EAPI const char *elm_theme_group_path_find(Elm_Theme *th, const char *group); @@ -471,6 +472,7 @@ EAPI const char *elm_theme_group_path_find(Elm_Theme *th, const char *group); * stringshared string to be freed with eina_stringshare_del(). Not doing so * may result in a leak. * + * @since 1.8 * @ingroup Theme */ EAPI Eina_List *elm_theme_group_base_list(Elm_Theme *th, const char *base); @@ -485,6 +487,7 @@ EAPI const char *elm_theme_group_path_find(Elm_Theme *th, const char *group); * that wishes toiterate over the files in this folder and display them, for * example a theme selector. * + * @since 1.8 * @ingroup Theme */ EAPI const char *elm_theme_system_dir_get(void); @@ -502,6 +505,7 @@ EAPI const char *elm_theme_system_dir_get(void); * User themes are always looked for before system themes. The user theme * directory is normally expected to be writable by the user. * + * @since 1.8 * @ingroup Theme */ EAPI const char *elm_theme_user_dir_get(void); --
Re: [E-devel] [e-users] Is there *real* documentation for edje?
On Fri, Nov 1, 2013 at 10:05 AM, Carsten Haitzler wrote: > On Thu, 31 Oct 2013 22:22:04 + Andrew F > said: > there is no chance we can compete with qt docs. not on the coldest day in hell > will it freeze over. qt literally has a whole pile of DEDICATED documentation > people paid fulltime... and have been paid fulltime for many years. we have > zero. > > doing documentation for us means NOT adding features developers need/want. it > means not optimizing things to be faster that developers want (and that > competing toolkits keep doing too). it means not reviewing patches that come > in. it means not fixing bugs that exist. it basically means not doing code. > it's > a choice of using an existing resource for something else. > > let me give you an example on how much work it takes to do docs. > > http://git.enlightenment.org/core/elementary.git/commit/?id=37fe9cc77144fe42e054a082ed58a4c52a961d35 > > specifically look at the docs i wrote in the header. those very basic docs > took > about as long to write as the code itself. writing docs is a time-consuming > effort. going beyond the docs i wrote there to write up a dialog on the > reasoning for those api's, several examples, and so on will blow out the time > needed even more. it's all a matter of time. unless we get a massive community > effort behind writing lots of documentation we're not going to go very far and > the code will be the thing that suffers. > > to say that efl is not documented is wrong. > > http://www.enlightenment.org/p.php?p=docs > > saying that it could be better - sure. but how much effort for how much gain? > just talking efl here. not e17/18 internal code and other apps. my current > count for api's in efl + elm is 6350 or so. that's NOT including all the > enums, > structs etc. so let's make that an even 7000 if we throw all of those in shall > we?. "good" documentation might average 2 pages of printed text per api > (7000). > that means not just the description and prototype but also reasoning, usage > examples, diagrams, etc. so that's 14000 pages of documentation. that's 114 > copies of war and peace. by all accounts it took tolstoy about 6 years to > write > it. that would mean we need 684 MAN YEARS of effort to write up what people > see > as "good documentation" for efl in its current state. so let's say we want to > get this done... we need about $54 million to hire all the writers... :) > > and that's just documenting all the elements of efl (api's) - it's not writing > all the introductions, overviews and associated docs that glue these together. > so let's round that up to 800 man years then. that's $64 millon... (assuming > average salary of a writer would be $80k/year including all overheads). > > just saying... it's a LOT of work... and it's not cheap. this simply can't be > done without a majorly large lump of money or a massively distributed > community > effort. Basically the only way to solve it is a community effort. It is something beginners can take on and we will review there contribution. It is something definitively valuable, but not something the small team of core developers can take care of. So take this as a huge call for contribution, where any help is welcomed ! -- Cedric BAIL -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eolian meta-data parsing
Hello,
On Fri, Nov 1, 2013 at 12:21 AM, Tom Hacohen wrote:
> On 21/10/13 18:29, daniel.za...@samsung.com wrote:
>> I would like to discuss about a project that we are beginning just now.
>> I presented it on EFL dev. day yesterday but I would like to share it
>> here since it will imply all the EFL developers (yes, you) one day or
>> another.
>>
>> It is called Eolian and was first aimed to facilitate addition of new Eo
>> functions by auto-generating code. Then we noted that we can
>> automatically generate language bindings too but it is not the goal of
>> this discussion.
>>
>> The idea is that each Eo class is represented into a .eo file. These
>> files are manually modified to add new functions, comments, callbacks...
>> and parsed and the generation phase updates the C/H files.
>>
>> They contain descriptions of inherited classes, properties, methods,
>> base classes implemented functions and callbacks.
>>
>> We thought about two formats:
>> - a C-like format:
>> Evas_Object_Image =
>> {
>> inherit
>> {
>> Evas_Object;
>> }
>> properties
>> {
>> /* Set the DPI resolution ... */
>> load_dpi(double dpi /* dpi resolution*/);
>> /* Apply the source object's clip to the proxy */
>> source_clip(Eina_Bool source_clip);
>> /* Set whether the image object's fill property ... */
>> filled(Eina_Bool filled);
>> /* Get the kind of looping the image object does. */
>> ro animated_loop_type(
>> Evas_Image_Animated_Loop_Hint hint /* hint */
>> );
>> /* Get the number times the animation of the object loops. */
>> ro animated_loop_count(
>> int loop_count
>> );
>> }
>> methods
>> {
>> /* Set the source object… */
>> source_set(
>> in Evas_Object* src /* in */,
>> out Eina_Bool* result /* out */
>> );
>> /* Get the current source object ... */
>> source_get(
>> out Evas_Object** src /* out */
>> );
>> /* Begin preloading an image … */
>> preload_begin();
>> /* Mark a sub-region of the given ... */
>> data_update_add(
>> in int x /* in */,
>> in int y /* in */,
>> in int w /* in */,
>> in int h /* in */
>> );
>> }
>> }
>>
>> For C developers that we are, it has the advantage to be easier to our
>> eyes. It fits most of the needs but still lacks for specific points:
>> - if we have a property whose comment is different for set and get, how
>> can we describe it? By inserting "tokens" inside the comments
>> themselves, meaning parsing of the comments is needed.
>> - if we want to define a function as virtual pure, do we use the so
>> loved C++ notation "= 0"?
>> - properties that are read-only or write-only (only get or set): do we
>> add some ro/wo parameter, as in the example?
>> ...
>> People complained that it seems too much like C++.
>>
>> - JSON format:
>> {
>> "class_name" : "Evas_Object_Image",
>> "inherits" : [ "Evas_Object" ],
>> "properties" : [
>> {
>> "name" : "load_dpi",
>> "description" : "DPI resolution ...",
>> "parameter" : [
>> {
>> "name" : "dpi",
>> "type" : "double",
>> "description" : "dpi resolution"
>> }
>> }
>> ... (don't have the force to write all ;-)
>> }
>> The format is less intuitive to C developers and there is more to write
>> but it is extensible and so easily solves the issues described in the
>> C-style.
>>
>> So, until yesterday (the day I presented), I really thought we would go
>> on the C (ok, C++) style but now that I saw some faces when I showed the
>> C format and since I want to come back home safe, I prefer asking here.
>>
>
> First of all, thank you Daniel for communicating your changes here. I
> think that Eolian has the potential to be an important foundation in the
> future of the EFL, so it's really important that it's good.
>
> Haven't read the whole thread yet, but there are a few comments I have
> to make:
> 1. A vote means nothing, we shouldn't go with something just because
> people prefer one buzzword over the other.
> 2. As raster has said, saying "we also have the parser ready for this"
> is like saying nothing. The "language" is in the strings themselves, not
> the few delimiters.
>
> I personally agree with raster, however I do prefer json in general. The
> question is: can me make something that works for us with json? The
> answer might be yes, might be no, needs to be evaluated, not arbitrarily
> voted on.
>
> Daniel: I think the main thing to see is how to make the best syntax.
> C(++?)-style, json or whatever. I would prefer something that is already
> well-defined like the structure that json provides, but maybe there
> involve a C-like syntax, so something more like:
>
> {
> "class_name" : "Evas_Object_Image",
> "inherits" : [ "Evas_Object" ],
> "properties" : [
> "load_dpi(double dpi)",
> "source_clip(Eina_Bool source_clip)",
I think that the following is more readable :
"properties" : [
"load_dpi": [ "dpi": "double" ],
"source_clip" : [ "source_clip": "Evas_Object" ],
"position" : [ "x" : "int", "y" : "int" ]
]
Also we need to define events and the associated data they will be
given. That is something mis
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 11:58 PM, Rafael Antognolli
wrote:
> On Thu, Oct 31, 2013 at 12:50 PM, Carsten Haitzler
> wrote:
>> On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL said:
>>> On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
>>> wrote:
>>> > On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler
>>> > wrote:
>>> >> On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL
>>> >> said:
>>> >>> On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
>>> >>> wrote:
>>> >>> > On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
>>> >>> > wrote:
>>> >>> >> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
>>> >>> >> wrote:
>>> >>> >>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
>>> >>> >>> wrote:
>>> >>> Hey everyone,
>>> >>>
>>> >>> Our current API for setting a window as fullscreen does not support
>>> >>> specifying which output/display/monitor should be used as
>>> >>> fullscreen.
>>> >>> However, wayland does support it.
>>> >>>
>>> >>> Would it make sense to have such parameter in the fullscreen_set
>>> >>> API?
>>> >>> Or should it be a wayland-only API?
>>> >>> >>>
>>> >>> >>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
>>> >>> >>> NULL = unset */
>>> >>> >>>
>>> >>> >>> the current version remains and sets on current display.
>>> >>> >>> Alternatively
>>> >>> >>> we could just move the window to another display before making that
>>> >>> >>> fullscreen, no idea if this is okay.
>>> >>> >>
>>> >>> >> Yeah, current version sets on current display (the one where the
>>> >>> >> non-fullscreen window is already displayed), unless it's the first
>>> >>> >> time that the window is going to be displayed. Otherwise it will use
>>> >>> >> the first output. But that's up to the compositor to choose so far,
>>> >>> >> unless we explicitly specify which output to use.
>>> >>> >>
>>> >>> For the latter case, how would we do that? Maybe exposing an API
>>> >>> that
>>> >>> allows to set the "preferred" output, and then when fullscreen_set
>>> >>> is
>>> >>> called, it just uses that one?
>>> >>> >>>
>>> >>> >>> I'd say we need to make this in one go, unless we want some kind of
>>> >>> >>> general assignment to one display (not just for FS mode).
>>> >>> >>
>>> >>> >> OK...
>>> >>> >>
>>> >>> >>>
>>> >>> There's also a need to specify how the output should be referred
>>> >>> to.
>>> >>> Using an (unsigned) int, where 0 is the first output, 1 is the
>>> >>> second, etc? Or maybe allowing to specify something like "always
>>> >>> the
>>> >>> biggest one in area", or the widest one, or whatever... any
>>> >>> thoughts?
>>> >>> >>>
>>> >>> >>> We'd need a way to enumerate the displays (or whatever we call them,
>>> >>> >>> like zone, etc), they should return their properties such as size,
>>> >>> >>> position (?), capabilities (3d/stereo? color? what do we have here?)
>>> >>> >>> and some string to make it easy to debug.
>>> >>> >>>
>>> >>> >>> we have the handle to it, so it can be windowsystem agnostic
>>> >>> >>> (Display_ID *, which can be implemented differently for windows,
>>> >>> >>> x11,
>>> >>> >>> wayland...)
>>> >>> >>
>>> >>> >> So you are proposing that we change a good portion of our API to be
>>> >>> >> aware of multiple displays?
>>> >>> >>
>>> >>> >>>
>>> >>> That reminds me that we still have another problem. APIs such
>>> >>> ecore_wl_screen_size_get() return only the screen size of the first
>>> >>> monitor, not both.
>>> >>> >>>
>>> >>> >>> same as above, this should be based on current window (if there is a
>>> >>> >>> window handle) or the first one (if there is not, alterntively we
>>> >>> >>> can
>>> >>> >>> state it will refer to screen the mouse is over, but I guess this is
>>> >>> >>> incorrect and makes everything less predictable).
>>> >>> >>
>>> >>> >> Well, that API has no argument, so it just assumes the current
>>> >>> >> output.
>>> >>> >> For a given window, one could use ecore_evas_screen_geometry_get, and
>>> >>> >> that indeed will be attached to a given display, but only after the
>>> >>> >> Ecore_Evas has been shown first (at least on Wayland, if I'm not
>>> >>> >> wrong).
>>> >>> >>
>>> >>> What about a common API to select which output we are talking
>>> >>> about,
>>> >>> that must be called before any call that would refer to a specific
>>> >>> output? The problem with this is that it would make code very
>>> >>> wayland-specific :-/
>>> >>> >>>
>>> >>> >>> how so? just use the opaque handlers and abstract stuff in there.
>>> >>> >>
>>> >>> >> OK, so you suggestion is something like:
>>> >>> >>
>>> >>> >> Display {
>>> >>> >> ID;
>>> >>> >> size;
>>> >>> >> position; // might be some info from xrandr, like right-of another
>>> >>> >> display, etc, if that is even possible
>>> >>> >> capabilities (3d/stereo? color?)
>>> >>> >> dpi (I'm not even sure if we can que
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
Hello,
On Fri, Nov 1, 2013 at 5:45 AM, Bertrand Jacquin wrote:
> Here is the list of last *git write* access from enable users with that
> some ugly script :
>
> getent passwd \
>| awk -F : '
>{
> if ($3 >= 1000 && $3 <= && $7 != "/sbin/nologin") {
>print $1
> }
>}' \
>| while read ; do
>awk -v REPLY="${REPLY}" -v LAST=never '
> {
>if ($2 == REPLY && $4 = "git-receive-pack") {
> LAST=$1
>}
> }
>
> END {
>print REPLY,LAST
> }' /var/log/gitolite/gitolite-*.log
> done \
>| sort -k 2 | column -t
>
> acidx never
> aron never
> ceolin never
> dresb never
> ewww never
> fidencio never
> gouachenever
> incnever
> kakaroto never
> mello never
> mickeylnever
> monkeyiq never
> morlenxus never
> nash never
> pespin never
> playya never
> raoul never
> rfonseca never
> ruinever
> shorne never
> sohyun never
> turran never
> vapier never
> watchwolf never
> xhell never
> mej2013-03-25.09:48:07
> andreas2013-05-18.04:52:14
> gastal 2013-06-06.11:50:36
> rakuco 2013-06-26.06:26:52
> mekius 2013-07-08.17:22:09
> thanatermesis 2013-08-02.06:32:06
> tiago 2013-08-23.12:20:41
> bdilly 2013-09-02.14:30:44
> garik 2013-09-03.17:11:56
> kimcinoo 2013-09-10.17:57:03
> jypark 2013-09-12.01:43:39
> jeffdameth 2013-10-02.14:26:17
> princeamd 2013-10-03.05:35:25
> mike_m 2013-10-06.15:02:43
> quaker 2013-10-07.09:16:59
> dorileo2013-10-15.13:29:13
> asdfuser 2013-10-16.00:05:44
> jaehwan2013-10-17.04:00:28
> sanjeev2013-10-17.05:59:19
> okra 2013-10-17.10:10:06
> jihoon 2013-10-17.18:23:00
> glima 2013-10-18.13:29:26
> kiwi 2013-10-18.19:17:07
> captainigloo 2013-10-18.21:54:23
> kwo2013-10-19.10:36:26
> billiob2013-10-20.03:45:11
> illogict 2013-10-21.10:46:34
> demarchi 2013-10-24.14:38:48
> beber 2013-10-25.02:04:52
> etrunko2013-10-25.18:36:25
> stefan 2013-10-26.03:14:42
> maxerba2013-10-26.03:41:45
> onefang2013-10-26.08:22:49
> jackdanielz2013-10-27.01:09:45
> davemds2013-10-28.15:51:17
> ravenlock 2013-10-28.18:54:29
> ngc891 2013-10-29.03:30:26
> hyoyoung 2013-10-29.07:55:17
> zehortigoza2013-10-29.11:17:11
> barbieri 2013-10-29.15:43:12
> sung 2013-10-29.23:27:57
> yakov 2013-10-30.02:52:25
> ulisses2013-10-30.07:35:56
> sachiel2013-10-30.11:02:33
> kuuko 2013-10-30.12:02:57
> discomfitor2013-10-30.14:25:55
> yoz2013-10-30.17:04:55
> jpeg 2013-10-30.18:12:46
> englebass 2013-10-31.00:17:03
> woohyun2013-10-31.00:51:09
> hermet 2013-10-31.01:04:25
> leif 2013-10-31.02:50:45
> ryuan 2013-10-31.05:43:18
> cedric 2013-10-31.06:21:22
> seoz 2013-10-31.07:02:33
> antognolli 2013-10-31.07:09:28
> urandom2013-10-31.07:49:43
> tasn 2013-10-31.09:05:23
> devilhorns 2013-10-31.10:22:47
> raster 2013-10-31.11:03:46
> jeyzu 2013-10-31.11:13:21
> uartie 2013-10-31.11:45:41
> kuri 2013-10-31.13:08:38
Thanks for the list. I would just argue that we have moved to git less
than a year ago. So maybe we should go over that list again for the
one year anniversary of our move to git.
--
Cedric BAIL
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Is there *real* documentation for edje?
On Thu, 31 Oct 2013 22:22:04 + Andrew F said: there is no chance we can compete with qt docs. not on the coldest day in hell will it freeze over. qt literally has a whole pile of DEDICATED documentation people paid fulltime... and have been paid fulltime for many years. we have zero. doing documentation for us means NOT adding features developers need/want. it means not optimizing things to be faster that developers want (and that competing toolkits keep doing too). it means not reviewing patches that come in. it means not fixing bugs that exist. it basically means not doing code. it's a choice of using an existing resource for something else. let me give you an example on how much work it takes to do docs. http://git.enlightenment.org/core/elementary.git/commit/?id=37fe9cc77144fe42e054a082ed58a4c52a961d35 specifically look at the docs i wrote in the header. those very basic docs took about as long to write as the code itself. writing docs is a time-consuming effort. going beyond the docs i wrote there to write up a dialog on the reasoning for those api's, several examples, and so on will blow out the time needed even more. it's all a matter of time. unless we get a massive community effort behind writing lots of documentation we're not going to go very far and the code will be the thing that suffers. to say that efl is not documented is wrong. http://www.enlightenment.org/p.php?p=docs saying that it could be better - sure. but how much effort for how much gain? just talking efl here. not e17/18 internal code and other apps. my current count for api's in efl + elm is 6350 or so. that's NOT including all the enums, structs etc. so let's make that an even 7000 if we throw all of those in shall we?. "good" documentation might average 2 pages of printed text per api (7000). that means not just the description and prototype but also reasoning, usage examples, diagrams, etc. so that's 14000 pages of documentation. that's 114 copies of war and peace. by all accounts it took tolstoy about 6 years to write it. that would mean we need 684 MAN YEARS of effort to write up what people see as "good documentation" for efl in its current state. so let's say we want to get this done... we need about $54 million to hire all the writers... :) and that's just documenting all the elements of efl (api's) - it's not writing all the introductions, overviews and associated docs that glue these together. so let's round that up to 800 man years then. that's $64 millon... (assuming average salary of a writer would be $80k/year including all overheads). just saying... it's a LOT of work... and it's not cheap. this simply can't be done without a majorly large lump of money or a massively distributed community effort. > enlightenment desktop is getting a lot of attention with e17. Good Speed, > good looks, and great features. > Maybe its time we step back and look at where we are going and what that > means. If Enlightenment is going big time, we are going to have more > qualified programmers join the project and they deserve to have decent > documentation. After all, why should we make it harder for them to get up > to speed. If they are joining the project, lets make it as easy as > possible. > > S > strong > documentation to strengthen the project. > P > erhaps we can brake the information up into logical chapters and have > different people or teams of people write specific chapters. > > Look at QT, they are getting huge and their documentation is exceptional. > Its easy for developers to get up to speed.Their success is directly > related to how easy it is to learn to program QT. > I think we should follow that model to help e17 grow even faster. > > We need an editor to outline the document, create the table of contents and > manage volunteers who will write the individual chapters. > > Who has the knowledge of e17 to do this? > > > On Thu, Oct 31, 2013 at 2:49 PM, Carsten Haitzler wrote: > > > On Thu, 31 Oct 2013 09:02:04 -0300 Vinícius dos Santos Oliveira > > said: > > > > > Em Qui, 2013-10-31 às 08:51 +0900, Carsten Haitzler escreveu: > > > > > > > i know. i spent some of my early life on unix/linux paying large sums > > > > for > > > > o'reilly books. and reading them cover to cover. they had diagrams. i > > > > frankly > > > > far prefer raw simple code over those books. the code is digestible in > > > > a > > > > fraction of the time. :) if i have an actual working bit of code i can > > > > compile > > > > it, run it and then modify it to see how it wobbles when poked. poke a > > > > bit more > > > > and see some more wobbling. these wobbles tell me the story of how > > > > CHANGES to > > > > the example affect the behaviour. start small with small changes and > > > > see. :) a > > > > book doesn't give me that. english words don't give me that. code > > > > does. :) but > > > > that is my style - i know that within all fields of education > > > > including foreign > > > > languages, math, sc
Re: [E-devel] [e-users] Is there *real* documentation for edje?
Hey guys, can someone point me to documentation that explains what a swallow is? and how its used. thanks On Thu, Oct 31, 2013 at 10:22 PM, Andrew F wrote: > enlightenment desktop is getting a lot of attention with e17. Good Speed, > good looks, and great features. > Maybe its time we step back and look at where we are going and what that > means. If Enlightenment is going big time, we are going to have more > qualified programmers join the project and they deserve to have decent > documentation. After all, why should we make it harder for them to get up > to speed. If they are joining the project, lets make it as easy as > possible. > > S > strong > documentation to strengthen the project. > P > erhaps we can brake the information up into logical chapters and have > different people or teams of people write specific chapters. > > Look at QT, they are getting huge and their documentation is exceptional. > Its easy for developers to get up to speed.Their success is directly > related to how easy it is to learn to program QT. > I think we should follow that model to help e17 grow even faster. > > We need an editor to outline the document, create the table of contents > and manage volunteers who will write the individual chapters. > > Who has the knowledge of e17 to do this? > > > On Thu, Oct 31, 2013 at 2:49 PM, Carsten Haitzler wrote: > >> On Thu, 31 Oct 2013 09:02:04 -0300 Vinícius dos Santos Oliveira >> said: >> >> > Em Qui, 2013-10-31 às 08:51 +0900, Carsten Haitzler escreveu: >> > >> > > i know. i spent some of my early life on unix/linux paying large sums >> > > for >> > > o'reilly books. and reading them cover to cover. they had diagrams. i >> > > frankly >> > > far prefer raw simple code over those books. the code is digestible in >> > > a >> > > fraction of the time. :) if i have an actual working bit of code i can >> > > compile >> > > it, run it and then modify it to see how it wobbles when poked. poke a >> > > bit more >> > > and see some more wobbling. these wobbles tell me the story of how >> > > CHANGES to >> > > the example affect the behaviour. start small with small changes and >> > > see. :) a >> > > book doesn't give me that. english words don't give me that. code >> > > does. :) but >> > > that is my style - i know that within all fields of education >> > > including foreign >> > > languages, math, science, etc. etc. i always gravitated to "learn by >> > > example". >> > > i naturally break up the examples into their constituent parts and >> > > know how to >> > > manipulate them - the pattern builds over time naturally. >> > >> > >> > Code is interactive. School and all non-interactive shit is difficult >> > and pain to learn (at least for me and for you). >> > >> > But... I wonder how you avoid undefined behaviour code that can break in >> > the next release of the lib/compiler or in the second compiler/platform. >> >> experience teaches... and of course reading docs/references. >> >> -- >> - Codito, ergo sum - "I code, therefore I am" -- >> The Rasterman (Carsten Haitzler)ras...@rasterman.com >> >> >> >> -- >> Android is increasing in popularity, but the open development platform >> that >> developers love is also attractive to malware creators. Download this >> white >> paper to learn more about secure code signing practices that can help keep >> Android apps secure. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Releases pending
On Thu, Oct 31, 2013 at 10:24 PM, Eduardo Lima (Etrunko) wrote: > On Sun, Oct 13, 2013 at 6:52 AM, Thomas Sachau wrote: >> Thomas Sachau schrieb: >>> Eduardo Lima (Etrunko) schrieb: Fresh new Enlightenment and Elementary. Also, not so new Ecore which was not sent to the ML. >>> >>> The black screen with old config still exists. >> >> Also attached a "bt full" from a segfault with the pre-release of e17 >> >> >> -- >> >> Thomas Sachau >> Gentoo Linux Developer >> > > I have uploaded new versions for all packages (missed the track of > packages a while ago). As suggested by raster, bumped the config > version of the Randr config file in Enlightement, which should fix the > blank screen issue. I have also started a wiki page for this release > (https://phab.enlightenment.org/phriction/edit/?slug=minor_releases/efl_1_7_9_e_0_17_5/) > Actual link is https://phab.enlightenment.org/w/minor_releases/efl_1_7_9_e_0_17_5/ > There are some known bugs but no one is currently taking care of them. > As we are approaching a new major release (EFL 1.8/E18) I am inclined > to release as is and push the fixes for the next version. > > Let me know about the blank screen issue, if it doesn't fix the > problem, I will try to bump the epoch in config in an attempt to wipe > the whole configuration for xrandr. > > Regards, Etrunko > > -- > Eduardo de Barros Lima ◤✠◢ > ebl...@gmail.com -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Releases pending
On Sun, Oct 13, 2013 at 6:52 AM, Thomas Sachau wrote: > Thomas Sachau schrieb: >> Eduardo Lima (Etrunko) schrieb: >>> Fresh new Enlightenment and Elementary. Also, not so new Ecore which >>> was not sent to the ML. >> >> The black screen with old config still exists. > > Also attached a "bt full" from a segfault with the pre-release of e17 > > > -- > > Thomas Sachau > Gentoo Linux Developer > I have uploaded new versions for all packages (missed the track of packages a while ago). As suggested by raster, bumped the config version of the Randr config file in Enlightement, which should fix the blank screen issue. I have also started a wiki page for this release (https://phab.enlightenment.org/phriction/edit/?slug=minor_releases/efl_1_7_9_e_0_17_5/) There are some known bugs but no one is currently taking care of them. As we are approaching a new major release (EFL 1.8/E18) I am inclined to release as is and push the fixes for the next version. Let me know about the blank screen issue, if it doesn't fix the problem, I will try to bump the epoch in config in an attempt to wipe the whole configuration for xrandr. Regards, Etrunko -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [bindings/python/python-efl] master 01/02: Elementary.datetime_elm: Fix an API bug.
kuuko pushed a commit to branch master. http://git.enlightenment.org/bindings/python/python-efl.git/commit/?id=7826e96e0176acadf31f02c14baf03873eef2f92 commit 7826e96e0176acadf31f02c14baf03873eef2f92 Author: Kai Huuhko Date: Thu Oct 31 23:12:06 2013 +0200 Elementary.datetime_elm: Fix an API bug. --- efl/elementary/datetime_elm.pyx | 48 ++--- 1 file changed, 26 insertions(+), 22 deletions(-) diff --git a/efl/elementary/datetime_elm.pyx b/efl/elementary/datetime_elm.pyx index fab0b02..82fe719 100644 --- a/efl/elementary/datetime_elm.pyx +++ b/efl/elementary/datetime_elm.pyx @@ -463,35 +463,39 @@ cdef class Datetime(Object): time.tm_isdst = tmtup.tm_isdst elm_datetime_value_min_set(self.obj, &time) -property field_limit: -"""The field limits of a field. +def field_limit_get(self, Elm_Datetime_Field_Type fieldtype): +"""Get the field limits of a field. -Limits can be set to individual fields, independently, except for -AM/PM field. Any field can display the values only in between these -Minimum and Maximum limits unless the corresponding time value is -restricted from MinTime to MaxTime. That is, Min/ Max field limits -always works under the limitations of MinTime/ MaxTime. +Limits can be set to individual fields, independently, except for AM/PM field. +Any field can display the values only in between these Minimum and Maximum limits unless +the corresponding time value is restricted from MinTime to MaxTime. +That is, Min/ Max field limits always works under the limitations of MinTime/ MaxTime. There is no provision to set the limits of AM/PM field. -Type of the field. ELM_DATETIME_YEAR etc. -Reference to field's minimum value -Reference to field's maximum value +:param fieldtype: Type of the field. ELM_DATETIME_YEAR etc. + +""" +cdef int min, max +elm_datetime_field_limit_get(self.obj, fieldtype, &min, &max) +return min, max + +def field_limit_set(self, Elm_Datetime_Field_Type fieldtype, int min, int max): +"""Set the field limits of a field. -type: (:ref:`Elm_Datetime_Field_Type`, int, int) +Limits can be set to individual fields, independently, except for AM/PM field. +Any field can display the values only in between these Minimum and Maximum limits unless +the corresponding time value is restricted from MinTime to MaxTime. +That is, Min/ Max field limits always works under the limitations of MinTime/ MaxTime. + +There is no provision to set the limits of AM/PM field. + +:param Elm_Datetime_Field_Type fieldtype: Type of the field. ELM_DATETIME_YEAR etc. +:param int min: Reference to field's minimum value +:param int max: Reference to field's maximum value """ -def __get__(self): -cdef int min, max -cdef Elm_Datetime_Field_Type fieldtype = ELM_DATETIME_YEAR -elm_datetime_field_limit_get(self.obj, fieldtype, &min, &max) -return (fieldtype, min, max) - -def __set__(self, value): -cdef int min, max -cdef Elm_Datetime_Field_Type fieldtype -min, max, fieldtype = value -elm_datetime_field_limit_set(self.obj, fieldtype, min, max) +elm_datetime_field_limit_set(self.obj, fieldtype, min, max) property value: """The current value of a field. --
[EGIT] [core/efl] master 01/04: ecore/wayland: Hide Ecore_Wl_Display.
antognolli pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=35d2f195de262d846c5e3f6dc5634921afe46606
commit 35d2f195de262d846c5e3f6dc5634921afe46606
Author: Rafael Antognolli
Date: Thu Oct 31 18:02:04 2013 -0200
ecore/wayland: Hide Ecore_Wl_Display.
This struct is only used inside ecore_wayland itself, so there's no real
reason to expose it. Apparently, hiding it doesn't break anything,
except for the ecore_imf wayland module, which was easily fixed.
If anyone notices a breakage, please let me know.
---
src/lib/ecore_wayland/Ecore_Wayland.h | 44 ++-
src/lib/ecore_wayland/ecore_wl_private.h | 42 ++
src/modules/ecore_imf/wayland/wayland_imcontext.c | 9 +++--
3 files changed, 51 insertions(+), 44 deletions(-)
diff --git a/src/lib/ecore_wayland/Ecore_Wayland.h
b/src/lib/ecore_wayland/Ecore_Wayland.h
index 7828281..d7b6c69 100644
--- a/src/lib/ecore_wayland/Ecore_Wayland.h
+++ b/src/lib/ecore_wayland/Ecore_Wayland.h
@@ -31,7 +31,8 @@
extern "C" {
#endif
-typedef struct _Ecore_Wl_Display Ecore_Wl_Display;
+typedef struct _Ecore_Wl_Display Ecore_Wl_Display; /** FIXME: move to private
*/
+
typedef struct _Ecore_Wl_Output Ecore_Wl_Output;
typedef struct _Ecore_Wl_Input Ecore_Wl_Input;
typedef struct _Ecore_Wl_Global Ecore_Wl_Global; /** @since 1.7.6 */
@@ -95,47 +96,6 @@ struct _Ecore_Wl_Global
struct wl_list link;
};
-struct _Ecore_Wl_Display
-{
- struct
- {
-struct wl_display *display;
-struct wl_registry *registry;
-struct wl_compositor *compositor;
-struct wl_subcompositor *subcompositor;
-struct wl_shell *shell;
-struct wl_shell *desktop_shell;
-struct wl_shm *shm;
-struct wl_data_device_manager *data_device_manager;
- } wl;
-
- int fd;
- unsigned int mask;
- unsigned int serial;
- int sync_ref_count;
- Ecore_Fd_Handler *fd_hdl;
- Ecore_Idle_Enterer *idle_enterer;
-
- struct wl_list inputs;
- struct wl_list outputs;
- struct wl_list globals; /** @since 1.7.6 */
-
- Eina_Bool init_done;
-
- struct
- {
-struct xkb_context *context;
- } xkb;
-
- struct wl_cursor_theme *cursor_theme;
-
- Ecore_Wl_Output *output;
- Ecore_Wl_Input *input;
-
- void (*output_configure)(Ecore_Wl_Output *output, void *data);
- void *data;
-};
-
struct _Ecore_Wl_Output
{
Ecore_Wl_Display *display;
diff --git a/src/lib/ecore_wayland/ecore_wl_private.h
b/src/lib/ecore_wayland/ecore_wl_private.h
index 581774b..fdbd3c9 100644
--- a/src/lib/ecore_wayland/ecore_wl_private.h
+++ b/src/lib/ecore_wayland/ecore_wl_private.h
@@ -50,6 +50,48 @@ extern Ecore_Wl_Display *_ecore_wl_disp;
# endif
# define CRIT(...) EINA_LOG_DOM_CRIT(_ecore_wl_log_dom, __VA_ARGS__)
+
+struct _Ecore_Wl_Display
+{
+ struct
+ {
+struct wl_display *display;
+struct wl_registry *registry;
+struct wl_compositor *compositor;
+struct wl_subcompositor *subcompositor;
+struct wl_shell *shell;
+struct wl_shell *desktop_shell;
+struct wl_shm *shm;
+struct wl_data_device_manager *data_device_manager;
+ } wl;
+
+ int fd;
+ unsigned int mask;
+ unsigned int serial;
+ int sync_ref_count;
+ Ecore_Fd_Handler *fd_hdl;
+ Ecore_Idle_Enterer *idle_enterer;
+
+ struct wl_list inputs;
+ struct wl_list outputs;
+ struct wl_list globals; /** @since 1.7.6 */
+
+ Eina_Bool init_done;
+
+ struct
+ {
+struct xkb_context *context;
+ } xkb;
+
+ struct wl_cursor_theme *cursor_theme;
+
+ Ecore_Wl_Output *output;
+ Ecore_Wl_Input *input;
+
+ void (*output_configure)(Ecore_Wl_Output *output, void *data);
+ void *data;
+};
+
struct _Ecore_Wl_Dnd
{
Ecore_Wl_Display *ewd;
diff --git a/src/modules/ecore_imf/wayland/wayland_imcontext.c
b/src/modules/ecore_imf/wayland/wayland_imcontext.c
index a3e88d3..07072e4 100644
--- a/src/modules/ecore_imf/wayland/wayland_imcontext.c
+++ b/src/modules/ecore_imf/wayland/wayland_imcontext.c
@@ -39,6 +39,7 @@ struct _WaylandIMContext
struct wl_text_input *text_input;
Ecore_Wl_Window *window;
+ Ecore_Wl_Input *input;
Evas*canvas;
char *preedit_text;
@@ -627,6 +628,8 @@ wayland_im_context_focus_in(Ecore_IMF_Context *ctx)
if (!input || !input->seat)
return;
+ imcontext->input = input;
+
if (imcontext->text_input)
{
wl_text_input_show_input_panel(imcontext->text_input);
@@ -643,11 +646,13 @@ wayland_im_context_focus_out(Ecore_IMF_Context *ctx)
EINA_LOG_DOM_INFO(_ecore_imf_wayland_log_dom, "focus-out");
- if (!imcontext->window) return;
+ if (!imcontext->input) return;
if (imcontext->text_input)
wl_text_input_deactivate(imcontext->text_input,
- imcontext->window->display->input->seat);
+ imcontext->input->seat);
+
+ imco
[EGIT] [core/efl] master 02/04: ecore/wayland: Make Ecore_Wl_Input private.
antognolli pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=e56428f4ad7b015c73b1959cf1d6aac154ca4ac0
commit e56428f4ad7b015c73b1959cf1d6aac154ca4ac0
Author: Rafael Antognolli
Date: Thu Oct 31 19:09:30 2013 -0200
ecore/wayland: Make Ecore_Wl_Input private.
It's mostly only used inside ecore_wayland library anyway.
The only bit needed outside of the library is the "seat" pointer, but a
new function was added to retrieve such pointer from Ecore_Wl_Input.
---
src/lib/ecore_wayland/Ecore_Wayland.h | 53 +--
src/lib/ecore_wayland/ecore_wl_input.c| 13 ++
src/lib/ecore_wayland/ecore_wl_private.h | 52 ++
src/modules/ecore_imf/wayland/wayland_imcontext.c | 12 +++--
4 files changed, 74 insertions(+), 56 deletions(-)
diff --git a/src/lib/ecore_wayland/Ecore_Wayland.h
b/src/lib/ecore_wayland/Ecore_Wayland.h
index d7b6c69..d190e0f 100644
--- a/src/lib/ecore_wayland/Ecore_Wayland.h
+++ b/src/lib/ecore_wayland/Ecore_Wayland.h
@@ -109,58 +109,6 @@ struct _Ecore_Wl_Output
void *data;
};
-struct _Ecore_Wl_Input
-{
- Ecore_Wl_Display *display;
- struct wl_seat *seat;
- struct wl_pointer *pointer;
- struct wl_keyboard *keyboard;
- struct wl_touch *touch;
-
- const char *cursor_name;
- struct wl_cursor *cursor;
- struct wl_surface *cursor_surface;
- struct wl_callback *cursor_frame_cb;
- Ecore_Timer *cursor_timer;
- unsigned int cursor_current_index;
-
- struct wl_data_device *data_device;
- struct wl_data_source *data_source;
- struct wl_array data_types;
-
- Ecore_Wl_Window *pointer_focus;
- Ecore_Wl_Window *keyboard_focus;
-
- unsigned int button;
- unsigned int timestamp;
- unsigned int modifiers;
- unsigned int pointer_enter_serial;
- int sx, sy;
-
- struct wl_list link;
-
- Ecore_Wl_Window *grab;
- unsigned int grab_button;
-
- Ecore_Wl_Dnd_Source *drag_source;
- Ecore_Wl_Dnd_Source *selection_source;
-
- struct
- {
-struct xkb_keymap *keymap;
-struct xkb_state *state;
-xkb_mod_mask_t control_mask;
-xkb_mod_mask_t alt_mask;
-xkb_mod_mask_t shift_mask;
- } xkb;
-
- struct
- {
-Ecore_Timer *tmr;
-unsigned int sym, key, time;
- } repeat;
-};
-
struct _Ecore_Wl_Window
{
Ecore_Wl_Display *display;
@@ -524,6 +472,7 @@ EAPI void ecore_wl_input_ungrab(Ecore_Wl_Input *input);
EAPI void ecore_wl_input_pointer_set(Ecore_Wl_Input *input, struct wl_surface
*surface, int hot_x, int hot_y);
EAPI void ecore_wl_input_cursor_from_name_set(Ecore_Wl_Input *input, const
char *cursor_name);
EAPI void ecore_wl_input_cursor_default_restore(Ecore_Wl_Input *input);
+EAPI struct wl_seat *ecore_wl_input_seat_get(Ecore_Wl_Input *input);
EAPI struct wl_list *ecore_wl_outputs_get(void);
diff --git a/src/lib/ecore_wayland/ecore_wl_input.c
b/src/lib/ecore_wayland/ecore_wl_input.c
index 2cdc1ec..bd1e010 100644
--- a/src/lib/ecore_wayland/ecore_wl_input.c
+++ b/src/lib/ecore_wayland/ecore_wl_input.c
@@ -287,6 +287,19 @@ ecore_wl_input_get(void)
return _ecore_wl_disp->input;
}
+/**
+ * @since 1.8
+ */
+EAPI struct wl_seat *
+ecore_wl_input_seat_get(Ecore_Wl_Input *input)
+{
+ LOGFN(__FILE__, __LINE__, __FUNCTION__);
+
+ if (!input) return NULL;
+
+ return input->seat;
+}
+
/* local functions */
void
_ecore_wl_input_add(Ecore_Wl_Display *ewd, unsigned int id)
diff --git a/src/lib/ecore_wayland/ecore_wl_private.h
b/src/lib/ecore_wayland/ecore_wl_private.h
index fdbd3c9..06be1a5 100644
--- a/src/lib/ecore_wayland/ecore_wl_private.h
+++ b/src/lib/ecore_wayland/ecore_wl_private.h
@@ -92,6 +92,58 @@ struct _Ecore_Wl_Display
void *data;
};
+struct _Ecore_Wl_Input
+{
+ Ecore_Wl_Display *display;
+ struct wl_seat *seat;
+ struct wl_pointer *pointer;
+ struct wl_keyboard *keyboard;
+ struct wl_touch *touch;
+
+ const char *cursor_name;
+ struct wl_cursor *cursor;
+ struct wl_surface *cursor_surface;
+ struct wl_callback *cursor_frame_cb;
+ Ecore_Timer *cursor_timer;
+ unsigned int cursor_current_index;
+
+ struct wl_data_device *data_device;
+ struct wl_data_source *data_source;
+ struct wl_array data_types;
+
+ Ecore_Wl_Window *pointer_focus;
+ Ecore_Wl_Window *keyboard_focus;
+
+ unsigned int button;
+ unsigned int timestamp;
+ unsigned int modifiers;
+ unsigned int pointer_enter_serial;
+ int sx, sy;
+
+ struct wl_list link;
+
+ Ecore_Wl_Window *grab;
+ unsigned int grab_button;
+
+ Ecore_Wl_Dnd_Source *drag_source;
+ Ecore_Wl_Dnd_Source *selection_source;
+
+ struct
+ {
+struct xkb_keymap *keymap;
+struct xkb_state *state;
+xkb_mod_mask_t control_mask;
+xkb_mod_mask_t alt_mask;
+xkb_mod_mask_t shift_mask;
+ } xkb;
+
+ struct
+ {
+Ecore_Timer *tmr;
+unsigned int sym, key, time;
+ } repeat;
+};
+
struct _Ecore_Wl_
[EGIT] [core/efl] master 04/04: ecore/wayland: Do not store "edges" in Ecore_Wl_Window.
antognolli pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=1deb107d56acd3e89a00d451b63920c0450e4668
commit 1deb107d56acd3e89a00d451b63920c0450e4668
Author: Rafael Antognolli
Date: Thu Oct 31 20:15:36 2013 -0200
ecore/wayland: Do not store "edges" in Ecore_Wl_Window.
This is a configure event info, so put it in the right place. Some
places adding edges info were also removed, which means that they were
redundant.
Tested with + middle click resize, and with window border resize,
on all the edges. Apparently, nothing breaks.
---
src/lib/ecore_wayland/Ecore_Wayland.h | 3 ++-
src/lib/ecore_wayland/ecore_wl_window.c| 27 +-
.../engines/wayland/ecore_evas_wayland_common.c| 2 +-
.../engines/wayland/ecore_evas_wayland_egl.c | 3 ---
.../engines/wayland/ecore_evas_wayland_shm.c | 3 ---
5 files changed, 9 insertions(+), 29 deletions(-)
diff --git a/src/lib/ecore_wayland/Ecore_Wayland.h
b/src/lib/ecore_wayland/Ecore_Wayland.h
index 899f80e..f9b70c7 100644
--- a/src/lib/ecore_wayland/Ecore_Wayland.h
+++ b/src/lib/ecore_wayland/Ecore_Wayland.h
@@ -125,7 +125,7 @@ struct _Ecore_Wl_Window
} pointer;
int id, surface_id;
- int edges, rotation;
+ int rotation;
Eina_Rectangle allocation;
@@ -213,6 +213,7 @@ struct _Ecore_Wl_Event_Window_Configure
unsigned int win;
unsigned int event_win;
int x, y, w, h;
+ int edges;
};
struct _Ecore_Wl_Event_Dnd_Enter
diff --git a/src/lib/ecore_wayland/ecore_wl_window.c
b/src/lib/ecore_wayland/ecore_wl_window.c
index 8307f65..661e825 100644
--- a/src/lib/ecore_wayland/ecore_wl_window.c
+++ b/src/lib/ecore_wayland/ecore_wl_window.c
@@ -10,7 +10,7 @@ static void _ecore_wl_window_cb_configure(void *data, struct
wl_shell_surface *s
static void _ecore_wl_window_cb_popup_done(void *data, struct wl_shell_surface
*shell_surface EINA_UNUSED);
static void _ecore_wl_window_cb_surface_enter(void *data, struct wl_surface
*surface, struct wl_output *output EINA_UNUSED);
static void _ecore_wl_window_cb_surface_leave(void *data, struct wl_surface
*surface, struct wl_output *output EINA_UNUSED);
-static void _ecore_wl_window_configure_send(Ecore_Wl_Window *win, int w, int
h);
+static void _ecore_wl_window_configure_send(Ecore_Wl_Window *win, int w, int
h, int edges);
static char *_ecore_wl_window_id_str_get(unsigned int win_id);
/* local variables */
@@ -219,17 +219,6 @@ ecore_wl_window_buffer_attach(Ecore_Wl_Window *win, struct
wl_buffer *buffer, in
case ECORE_WL_WINDOW_BUFFER_TYPE_SHM:
if (win->surface)
{
- if (win->edges & 4) // resizing from the left
- x = win->server.w - win->allocation.w;
- else
- x = 0;
-
- if (win->edges & 1) // resizing from the top
- y = win->server.h - win->allocation.h;
- else
- y = 0;
-
- win->edges = 0;
win->has_buffer = (buffer != NULL);
/* if (buffer) */
@@ -357,9 +346,8 @@ ecore_wl_window_maximized_set(Ecore_Wl_Window *win,
Eina_Bool maximized)
if (win->shell_surface)
wl_shell_surface_set_toplevel(win->shell_surface);
win->type = ECORE_WL_WINDOW_TYPE_TOPLEVEL;
-_ecore_wl_window_configure_send(win, win->saved.w, win->saved.h);
+_ecore_wl_window_configure_send(win, win->saved.w, win->saved.h, 0);
}
- win->edges = 0;
}
EAPI Eina_Bool
@@ -397,9 +385,8 @@ ecore_wl_window_fullscreen_set(Ecore_Wl_Window *win,
Eina_Bool fullscreen)
if (win->shell_surface)
wl_shell_surface_set_toplevel(win->shell_surface);
win->type = ECORE_WL_WINDOW_TYPE_TOPLEVEL;
-_ecore_wl_window_configure_send(win, win->saved.w, win->saved.h);
+_ecore_wl_window_configure_send(win, win->saved.w, win->saved.h, 0);
}
- win->edges = 0;
}
EAPI Eina_Bool
@@ -719,10 +706,7 @@ _ecore_wl_window_cb_configure(void *data, struct
wl_shell_surface *shell_surface
if ((win->allocation.w != w) || (win->allocation.h != h))
{
-if (win->type == ECORE_WL_WINDOW_TYPE_TOPLEVEL)
- win->edges = edges;
-
-_ecore_wl_window_configure_send(win, w, h);
+_ecore_wl_window_configure_send(win, w, h, edges);
}
}
@@ -761,7 +745,7 @@ _ecore_wl_window_cb_surface_leave(void *data, struct
wl_surface *surface, struct
}
static void
-_ecore_wl_window_configure_send(Ecore_Wl_Window *win, int w, int h)
+_ecore_wl_window_configure_send(Ecore_Wl_Window *win, int w, int h, int edges)
{
Ecore_Wl_Event_Window_Configure *ev;
@@ -774,6 +758,7 @@ _ecore_wl_window_configure_send(Ecore_Wl_Window *win, int
w, int h)
ev->y = win->allocation.y;
ev->w = w;
ev->h = h;
+ ev->edges = edges;
ecore_event_add(ECORE_WL_EVENT_WINDOW_CONFIGURE, ev, NULL, NULL);
}
diff --git a/src/modules/ecore_evas/engi
[EGIT] [core/efl] master 03/04: ecore/wayland: Do not use win->id directly.
antognolli pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=dd18206d860fa9cd1cea4ce01657c21678318bca
commit dd18206d860fa9cd1cea4ce01657c21678318bca
Author: Rafael Antognolli
Date: Thu Oct 31 20:02:40 2013 -0200
ecore/wayland: Do not use win->id directly.
Use a getter for it instead, so we don't need to expose the
Ecore_Wl_Window struct just because of it.
---
src/lib/ecore_wayland/Ecore_Wayland.h | 2 ++
src/lib/ecore_wayland/ecore_wl_window.c | 11 +++
.../ecore_evas/engines/wayland/ecore_evas_wayland_egl.c | 2 +-
.../ecore_evas/engines/wayland/ecore_evas_wayland_shm.c | 2 +-
src/modules/ecore_imf/wayland/wayland_imcontext.c | 4 ++--
5 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/lib/ecore_wayland/Ecore_Wayland.h
b/src/lib/ecore_wayland/Ecore_Wayland.h
index d190e0f..899f80e 100644
--- a/src/lib/ecore_wayland/Ecore_Wayland.h
+++ b/src/lib/ecore_wayland/Ecore_Wayland.h
@@ -626,6 +626,8 @@ EAPI void
ecore_wl_window_cursor_from_name_set(Ecore_Wl_Window *win, const char
EAPI void ecore_wl_window_cursor_default_restore(Ecore_Wl_Window *win);
EAPI void ecore_wl_window_parent_set(Ecore_Wl_Window *win, Ecore_Wl_Window
*parent);
+EAPI int ecore_wl_window_id_get(Ecore_Wl_Window *win);
+
/**
* Returns a wl_surface with no association to any wl_shell_surface.
*
diff --git a/src/lib/ecore_wayland/ecore_wl_window.c
b/src/lib/ecore_wayland/ecore_wl_window.c
index 0de39d9..8307f65 100644
--- a/src/lib/ecore_wayland/ecore_wl_window.c
+++ b/src/lib/ecore_wayland/ecore_wl_window.c
@@ -687,6 +687,17 @@ ecore_wl_window_rotation_get(Ecore_Wl_Window *win)
return win->rotation;
}
+/* @since 1.8 */
+EAPI int
+ecore_wl_window_id_get(Ecore_Wl_Window *win)
+{
+ LOGFN(__FILE__, __LINE__, __FUNCTION__);
+
+ if (!win) return 0;
+ return win->id;
+}
+
+
/* local functions */
static void
_ecore_wl_window_cb_ping(void *data EINA_UNUSED, struct wl_shell_surface
*shell_surface, unsigned int serial)
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c
index 369d7ca..6fd5627 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_egl.c
@@ -182,7 +182,7 @@ ecore_evas_wayland_egl_new_internal(const char *disp_name,
unsigned int parent,
wdata->win =
ecore_wl_window_new(p, x, y, w + fw, h + fh,
ECORE_WL_WINDOW_BUFFER_TYPE_EGL_WINDOW);
- ee->prop.window = wdata->win->id;
+ ee->prop.window = ecore_wl_window_id_get(wdata->win);
ee->evas = evas_new();
evas_data_attach_set(ee->evas, ee);
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c
index 6cf845e..9e8fc4d 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_shm.c
@@ -179,7 +179,7 @@ ecore_evas_wayland_shm_new_internal(const char *disp_name,
unsigned int parent,
wdata->win =
ecore_wl_window_new(p, x, y, w + fw, h + fh,
ECORE_WL_WINDOW_BUFFER_TYPE_SHM);
- ee->prop.window = wdata->win->id;
+ ee->prop.window = ecore_wl_window_id_get(wdata->win);
ee->evas = evas_new();
evas_data_attach_set(ee->evas, ee);
diff --git a/src/modules/ecore_imf/wayland/wayland_imcontext.c
b/src/modules/ecore_imf/wayland/wayland_imcontext.c
index 00a2dde..84d0a50 100644
--- a/src/modules/ecore_imf/wayland/wayland_imcontext.c
+++ b/src/modules/ecore_imf/wayland/wayland_imcontext.c
@@ -474,8 +474,8 @@ text_input_keysym(void *data,
strcpy((char *)e->key, key);
strcpy((char *)e->string, string);
- e->window = imcontext->window->id;
- e->event_window = imcontext->window->id;
+ e->window = ecore_wl_window_id_get(imcontext->window);
+ e->event_window = ecore_wl_window_id_get(imcontext->window);
e->timestamp = time;
e->modifiers = 0;
--
Re: [E-devel] [EGIT] [core/elementary] master 01/01: Fix elm client applications to support maximize properly (ie: removing border shadow and resizing properly).
On Thu, Oct 31, 2013 at 3:03 PM, Chris Michael wrote:
> devilhorns pushed a commit to branch master.
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=28763963bb9e26ea25ca182acc294c0a02f03ba2
>
> commit 28763963bb9e26ea25ca182acc294c0a02f03ba2
> Author: Chris Michael
> Date: Thu Oct 31 17:00:23 2013 +
>
> Fix elm client applications to support maximize properly (ie: removing
> border shadow and resizing properly).
Again, I fixed this on commit
ea3b9ea0f932f9d4446bb3d3a902908a12bcd3de, so these signals are already
being sent. There's no need for these extra callbacks, as I send the
signals on the only places where maximize is triggered.
> NB: Elm Theme needs fullscreen support old man !! :P
>
> Signed-off-by: Chris Michael
> ---
> src/lib/elm_win.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
> index 95f4812..12141c1 100644
> --- a/src/lib/elm_win.c
> +++ b/src/lib/elm_win.c
> @@ -2438,6 +2438,24 @@ _elm_win_frame_cb_close(void *data,
> evas_object_unref(win);
> }
>
> +static void
> +_elm_win_frame_obj_maximized(void *data, Evas_Object *obj, void *event)
> +{
> + Elm_Win_Smart_Data *sd;
> +
> + sd = data;
> + edje_object_signal_emit(sd->frame_obj, "elm,state,maximized", "elm");
> +}
> +
> +static void
> +_elm_win_frame_obj_unmaximized(void *data, Evas_Object *obj, void *event)
> +{
> + Elm_Win_Smart_Data *sd;
> +
> + sd = data;
> + edje_object_signal_emit(sd->frame_obj, "elm,state,unmaximized", "elm");
> +}
> +
> static void
> _elm_win_frame_add(Elm_Win_Smart_Data *sd,
> const char *style)
> @@ -2477,6 +2495,13 @@ _elm_win_frame_add(Elm_Win_Smart_Data *sd,
> evas_object_event_callback_add
> (sd->frame_obj, EVAS_CALLBACK_RESIZE, _elm_win_frame_obj_resize, sd);
>
> + /* FIXME: Elm Theme needs support for fullscreen state
> +* (elm,state,fullscreen/unfullscreen) */
> + evas_object_smart_callback_add(sd->obj, SIG_MAXIMIZED,
> + _elm_win_frame_obj_maximized, sd);
> + evas_object_smart_callback_add(sd->obj, SIG_UNMAXIMIZED,
> + _elm_win_frame_obj_unmaximized, sd);
> +
> /* NB: Do NOT remove these calls !! Needed to calculate proper
> * framespace on inital show of the window */
> edje_object_size_min_calc(sd->frame_obj, &mw, &mh);
> @@ -2536,6 +2561,11 @@ _elm_win_frame_del(Elm_Win_Smart_Data *sd)
> evas_object_event_callback_del_full
>(sd->frame_obj, EVAS_CALLBACK_RESIZE, _elm_win_frame_obj_resize,
> sd);
>
> +evas_object_smart_callback_del(sd->obj, SIG_MAXIMIZED,
> + _elm_win_frame_obj_maximized);
> +evas_object_smart_callback_del(sd->obj, SIG_UNMAXIMIZED,
> + _elm_win_frame_obj_unmaximized);
> +
> edje_object_signal_callback_del
>(sd->frame_obj, "elm,action,move,start", "elm",
>_elm_win_frame_cb_move_start);
>
> --
>
>
--
Rafael Antognolli
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: Ok, This actually fixes maximized state properly now :) Basically, we still need to account for frame height, but not frame width when we are maximizing.
On Thu, Oct 31, 2013 at 3:22 PM, Chris Michael wrote:
> devilhorns pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=20f6676eb6ed0020c07272c9f59a20faf6ff651c
>
> commit 20f6676eb6ed0020c07272c9f59a20faf6ff651c
> Author: Chris Michael
> Date: Thu Oct 31 17:21:33 2013 +
>
> Ok, This actually fixes maximized state properly now :) Basically, we
> still need to account for frame height, but not frame width when we
> are maximizing.
Wait, this is not true! It only makes sense with the current
elementary theme, but it shouldn't work with a theme where we do have
borders on left and right, not only top and bottom.
BTW, what are you trying to fix here? Yesterday I pushed commits to
both efl and elementary that are fixing maximize/unmaximize already.
Is there still any problem that I didn't notice? Without your commits
to efl and elementary, everything was working fine already for me...
> Signed-off-by: Chris Michael
> ---
> src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c | 7
> ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git
> a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
> b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
> index 7d3d444..4b99563 100644
> --- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
> +++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
> @@ -224,19 +224,20 @@ _ecore_evas_wl_common_cb_window_configure(void *data
> EINA_UNUSED, int type EINA_
>
> nw = ev->w;
> nh = ev->h;
> - if ((!ee->prop.maximized) && (!ee->prop.fullscreen))
> +
> + if (!ee->prop.fullscreen)
> {
> int fw = 0, fh = 0;
>
> evas_output_framespace_get(ee->evas, NULL, NULL, &fw, &fh);
> if ((ee->rotation == 90) || (ee->rotation == 270))
>{
> - nw = ev->w - fh;
> + if (!ee->prop.maximized) nw = ev->w - fh;
> nh = ev->h - fw;
>}
> else
>{
> - nw = ev->w - fw;
> + if (!ee->prop.maximized) nw = ev->w - fw;
> nh = ev->h - fh;
>}
> }
>
> --
>
>
--
Rafael Antognolli
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
Awesome Beber!
Daniel Juyung Seo (SeoZ)
On Nov 1, 2013 5:46 AM, "Bertrand Jacquin" wrote:
> Here is the list of last *git write* access from enable users with that
> some ugly script :
>
> getent passwd \
>| awk -F : '
>{
> if ($3 >= 1000 && $3 <= && $7 != "/sbin/nologin") {
>print $1
> }
>}' \
>| while read ; do
>awk -v REPLY="${REPLY}" -v LAST=never '
> {
>if ($2 == REPLY && $4 = "git-receive-pack") {
> LAST=$1
>}
> }
>
> END {
>print REPLY,LAST
> }' /var/log/gitolite/gitolite-*.log
> done \
>| sort -k 2 | column -t
>
> acidx never
> aron never
> ceolin never
> dresb never
> ewww never
> fidencio never
> gouachenever
> incnever
> kakaroto never
> mello never
> mickeylnever
> monkeyiq never
> morlenxus never
> nash never
> pespin never
> playya never
> raoul never
> rfonseca never
> ruinever
> shorne never
> sohyun never
> turran never
> vapier never
> watchwolf never
> xhell never
> mej2013-03-25.09:48:07
> andreas2013-05-18.04:52:14
> gastal 2013-06-06.11:50:36
> rakuco 2013-06-26.06:26:52
> mekius 2013-07-08.17:22:09
> thanatermesis 2013-08-02.06:32:06
> tiago 2013-08-23.12:20:41
> bdilly 2013-09-02.14:30:44
> garik 2013-09-03.17:11:56
> kimcinoo 2013-09-10.17:57:03
> jypark 2013-09-12.01:43:39
> jeffdameth 2013-10-02.14:26:17
> princeamd 2013-10-03.05:35:25
> mike_m 2013-10-06.15:02:43
> quaker 2013-10-07.09:16:59
> dorileo2013-10-15.13:29:13
> asdfuser 2013-10-16.00:05:44
> jaehwan2013-10-17.04:00:28
> sanjeev2013-10-17.05:59:19
> okra 2013-10-17.10:10:06
> jihoon 2013-10-17.18:23:00
> glima 2013-10-18.13:29:26
> kiwi 2013-10-18.19:17:07
> captainigloo 2013-10-18.21:54:23
> kwo2013-10-19.10:36:26
> billiob2013-10-20.03:45:11
> illogict 2013-10-21.10:46:34
> demarchi 2013-10-24.14:38:48
> beber 2013-10-25.02:04:52
> etrunko2013-10-25.18:36:25
> stefan 2013-10-26.03:14:42
> maxerba2013-10-26.03:41:45
> onefang2013-10-26.08:22:49
> jackdanielz2013-10-27.01:09:45
> davemds2013-10-28.15:51:17
> ravenlock 2013-10-28.18:54:29
> ngc891 2013-10-29.03:30:26
> hyoyoung 2013-10-29.07:55:17
> zehortigoza2013-10-29.11:17:11
> barbieri 2013-10-29.15:43:12
> sung 2013-10-29.23:27:57
> yakov 2013-10-30.02:52:25
> ulisses2013-10-30.07:35:56
> sachiel2013-10-30.11:02:33
> kuuko 2013-10-30.12:02:57
> discomfitor2013-10-30.14:25:55
> yoz2013-10-30.17:04:55
> jpeg 2013-10-30.18:12:46
> englebass 2013-10-31.00:17:03
> woohyun2013-10-31.00:51:09
> hermet 2013-10-31.01:04:25
> leif 2013-10-31.02:50:45
> ryuan 2013-10-31.05:43:18
> cedric 2013-10-31.06:21:22
> seoz 2013-10-31.07:02:33
> antognolli 2013-10-31.07:09:28
> urandom2013-10-31.07:49:43
> tasn 2013-10-31.09:05:23
> devilhorns 2013-10-31.10:22:47
> raster 2013-10-31.11:03:46
> jeyzu 2013-10-31.11:13:21
> uartie 2013-10-31.11:45:41
> kuri 2013-10-31.13:08:38
>
> On 2013-10-31 12:33, Tom Hacohen wrote:
> > Well, suggest a list. I don't think we can easily automate that (as we
> > don't have last-login anymore). Gitolite might have logs.
> >
> > --
> > Tom.
> >
> > On 31/10/13 09:15, ChunEon Park wrote:
> >> I think it's time to clean up the committers who hasn't worked
> >> recently so far.
> >>
> >>
> >> -Regards, Hermet-
> >>
> >> -Original Message-
> >> From: "Luis Felipe Strano Moraes"
> >> To: ;
> >> Cc:
> >> Sent: 2013-10-30 (수) 02:19:04
> >> Subject: [EGIT] [admin/devs] master 01/01: dev--
> >>
> >> lfelipe pushed a commit to branch master.
> >>
> >>
> http://git.enlightenment.org/admin/devs.git/commit/?id=0c76c52eb1d45b5391c78e3eb1245f4321620556
> >>
> >> commit 0c76c52eb1d45b5391c78e3eb1245f4321620556
> >> Author: Luis Felipe Strano Moraes @gmail.com>
> >> Date: Tue Oct 29 15:17:10 2013 -0200
> >>
> >> dev--
> >>
> >> haven't been working on anything e-related recently
> >> ---
> >> lfelipe/id_rsa.pub 1 -
> >> lfelipe/info.txt9 -
> >> 2 files changed, 10 deletions(-)
> >>
> >> diff --git a/lfelipe/id_rsa.pub b/lfelipe/id_rsa.pub
> >> deleted file mode 100644
> >> index 0b6ee4d..000
> >> --- a/lfelipe/id_rsa.pub
> >> +++ /dev/null
> >> @@ -1 +0,0 @@
> >> -ssh-rsa
> >>
> B3NzaC1yc2EBIwAAAQEA1QDVDA+CkAJLbwS5OLi2Ts/DCbIpc0buzttvavnzRPs9mTb7Cf/f
Re: [E-devel] [e-users] Is there *real* documentation for edje?
enlightenment desktop is getting a lot of attention with e17. Good Speed, good looks, and great features. Maybe its time we step back and look at where we are going and what that means. If Enlightenment is going big time, we are going to have more qualified programmers join the project and they deserve to have decent documentation. After all, why should we make it harder for them to get up to speed. If they are joining the project, lets make it as easy as possible. S strong documentation to strengthen the project. P erhaps we can brake the information up into logical chapters and have different people or teams of people write specific chapters. Look at QT, they are getting huge and their documentation is exceptional. Its easy for developers to get up to speed.Their success is directly related to how easy it is to learn to program QT. I think we should follow that model to help e17 grow even faster. We need an editor to outline the document, create the table of contents and manage volunteers who will write the individual chapters. Who has the knowledge of e17 to do this? On Thu, Oct 31, 2013 at 2:49 PM, Carsten Haitzler wrote: > On Thu, 31 Oct 2013 09:02:04 -0300 Vinícius dos Santos Oliveira > said: > > > Em Qui, 2013-10-31 às 08:51 +0900, Carsten Haitzler escreveu: > > > > > i know. i spent some of my early life on unix/linux paying large sums > > > for > > > o'reilly books. and reading them cover to cover. they had diagrams. i > > > frankly > > > far prefer raw simple code over those books. the code is digestible in > > > a > > > fraction of the time. :) if i have an actual working bit of code i can > > > compile > > > it, run it and then modify it to see how it wobbles when poked. poke a > > > bit more > > > and see some more wobbling. these wobbles tell me the story of how > > > CHANGES to > > > the example affect the behaviour. start small with small changes and > > > see. :) a > > > book doesn't give me that. english words don't give me that. code > > > does. :) but > > > that is my style - i know that within all fields of education > > > including foreign > > > languages, math, science, etc. etc. i always gravitated to "learn by > > > example". > > > i naturally break up the examples into their constituent parts and > > > know how to > > > manipulate them - the pattern builds over time naturally. > > > > > > Code is interactive. School and all non-interactive shit is difficult > > and pain to learn (at least for me and for you). > > > > But... I wonder how you avoid undefined behaviour code that can break in > > the next release of the lib/compiler or in the second compiler/platform. > > experience teaches... and of course reading docs/references. > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > -- > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [misc/entrance] master 01/01: entrance: many improvment * improve pam login * fix some profile mistake when login an user * use EINA_UNUSED * code refactoring * remove session log
REALLY Thx to understand my point of view ! I never wanted to minimize your help on this project. I just used git log from my memories, to explain why I do this patch in this way (Without taking care futur review of others devs). In september, I know you have worked before, on entrance, to fix it. And I told you at this time, I'll be happy to merge your changes after my commit, based on old source code. Because, I know it's a lot of work, to understand and dissect source code changes. In the respect for everyone, I will try to reduce the noise in the futur, that I can do with this kind of patch. Don't worry when entrance will be ready. I would do a big noise, in order to encourage as many people I can, to test it. For systemd, my plan is to work on next month, then I could help you. But today, I don't use this init system :(. With my best regards 2013/10/31 Carsten Haitzler > On Thu, 31 Oct 2013 00:51:21 +0100 Michaël Bouchaud said: > > > I will try to find my best words. > > Sorry to annoy you with a huge commit. But as I say before, I'm the main > > dev of entrance and the only one to take care about it. And I do it in my > > free times, as my contribution to the efl libraries and enlightenment > since > > a long time. > > Raster or cedric have made some contribution to entrance before. But it > was > > a long time ago. The last diff I see, from another than me, is from > raster, > > where is a diff is on a pam file (not C code). Raster don't see I > provide a > > file for debian-ubuntu pam... > > umm actually i did a lot more than that: > > e51ff8cd2501304d3cee33621a3e520204e4f4b9 > 38f369b419e9fef8090dc75b1321fb3d0a61c07a > c05de4d019d590157b2edabce1aa808e63f28da1 > 16d33cdc4df0cc9e5063bb9c8a0b5fb77d4dc7bc > 530e75cf7453398c059f3d6bc487766b83591a6d > 688276f3259eee7da29a3b7e046b0ab2c33365fd > 4d4cdc967c08fcd126704ece6b2d2394b91f1b22 > 981bf81dbb1820e2e74536926ab00336b58b43a1 > > all on sept 4. :) but either way - not a lot. :) > > > So I take this into account that an advanced user, who don't notice I > > provide this one. So I change my mind and today, I provide a debian pam > > file in first. (the second pam file is for gentoo or arch. Where I think > > user are welcome and get used to do some patch or custom cp for things to > > work, instead of ubuntu users...). > > But this is not the problem here. I just want you point out, I have some > > users who use entrance everyday and welcome to have the last revision to > > test it. We have migrated from svn to git. OK. They do it, and since I > > still have about 10 mails each months for entrance... > > as such entrance was in svn before and it's in git in the same way. thats > how > it was and how it continues. i think here is a little too much focus on > "rules" and what i see as a desire to build more bureaucracy that "everyone > must follow the rules" "fill out form x" "get approval y". it's heading > that > way. and that's a good way to lose developers. just leave entrance alone. > let > it do its thing. if yoz wants to mess with it - fine. until it's up on > enlightenment.org as a download tarball and something that the wider > project is > pushing/supporting, it doesn't much matter. ignore the commits on it unless > *YOU* use it and those commits affect you. :) the day yoz wants to push > entrance to become a released/up for download thing... lets deal with it > then > and maybe bring entrance under some more control. > > > Now I have 4 choices. > > - First one, try to do atomic commit to pleased you and have some review > > from nobody...(maybe cedric for some commit not all, where he will say > > nothing...). As I said before, I don't want to spare my time for that. > > - Second choice, don't do atomic commit... and nobody can (want) review > me. > > But I will annoy some people with my huge commit (where this people can > > configure mailing box to ignore it as said by kuri). > > i think just filtering (ignoring the commits) is the best way - if you > don't > care about the project.. ignore its commits. > > > - Third choice, as second choice don't do atomic commit, but my project > go > > in my dev dir. Here my user will be annoyed, because he don't be noticed > by > > recent changes and I lose my futur audience ... > > - Fourth choice, don't do atomic commit... and open my own github. And I > > will annoy my user for a last time and don't boring you again. > > i think this is the worst option. i think just keep entrance exactly as it > is. > keep doing your work. i sure am not going to review every commit to it > even if > they were perfectly scripted and gold plated with cherries on top. it's not > important to at this time. if i use entrance, i will whack at its code to > make > it work if it does not. if a feature doesn't work right - i'll fix it. if > it's > missing something i need - i'll add it. pretty simple. commits can always > be > reverted. > > > But in last, if the last choice comes to be the best one. I will be very > > sad
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
Thanks beber!
On Thu, Oct 31, 2013 at 8:45 PM, Bertrand Jacquin wrote:
> Here is the list of last *git write* access from enable users with that
> some ugly script :
>
> getent passwd \
>| awk -F : '
>{
> if ($3 >= 1000 && $3 <= && $7 != "/sbin/nologin") {
>print $1
> }
>}' \
>| while read ; do
>awk -v REPLY="${REPLY}" -v LAST=never '
> {
>if ($2 == REPLY && $4 = "git-receive-pack") {
> LAST=$1
>}
> }
>
> END {
>print REPLY,LAST
> }' /var/log/gitolite/gitolite-*.log
> done \
>| sort -k 2 | column -t
>
> acidx never
> aron never
> ceolin never
> dresb never
> ewww never
> fidencio never
> gouachenever
> incnever
> kakaroto never
> mello never
> mickeylnever
> monkeyiq never
> morlenxus never
> nash never
> pespin never
> playya never
> raoul never
> rfonseca never
> ruinever
> shorne never
> sohyun never
> turran never
> vapier never
> watchwolf never
> xhell never
> mej2013-03-25.09:48:07
> andreas2013-05-18.04:52:14
> gastal 2013-06-06.11:50:36
> rakuco 2013-06-26.06:26:52
> mekius 2013-07-08.17:22:09
> thanatermesis 2013-08-02.06:32:06
> tiago 2013-08-23.12:20:41
> bdilly 2013-09-02.14:30:44
> garik 2013-09-03.17:11:56
> kimcinoo 2013-09-10.17:57:03
> jypark 2013-09-12.01:43:39
> jeffdameth 2013-10-02.14:26:17
> princeamd 2013-10-03.05:35:25
> mike_m 2013-10-06.15:02:43
> quaker 2013-10-07.09:16:59
> dorileo2013-10-15.13:29:13
> asdfuser 2013-10-16.00:05:44
> jaehwan2013-10-17.04:00:28
> sanjeev2013-10-17.05:59:19
> okra 2013-10-17.10:10:06
> jihoon 2013-10-17.18:23:00
> glima 2013-10-18.13:29:26
> kiwi 2013-10-18.19:17:07
> captainigloo 2013-10-18.21:54:23
> kwo2013-10-19.10:36:26
> billiob2013-10-20.03:45:11
> illogict 2013-10-21.10:46:34
> demarchi 2013-10-24.14:38:48
> beber 2013-10-25.02:04:52
> etrunko2013-10-25.18:36:25
> stefan 2013-10-26.03:14:42
> maxerba2013-10-26.03:41:45
> onefang2013-10-26.08:22:49
> jackdanielz2013-10-27.01:09:45
> davemds2013-10-28.15:51:17
> ravenlock 2013-10-28.18:54:29
> ngc891 2013-10-29.03:30:26
> hyoyoung 2013-10-29.07:55:17
> zehortigoza2013-10-29.11:17:11
> barbieri 2013-10-29.15:43:12
> sung 2013-10-29.23:27:57
> yakov 2013-10-30.02:52:25
> ulisses2013-10-30.07:35:56
> sachiel2013-10-30.11:02:33
> kuuko 2013-10-30.12:02:57
> discomfitor2013-10-30.14:25:55
> yoz2013-10-30.17:04:55
> jpeg 2013-10-30.18:12:46
> englebass 2013-10-31.00:17:03
> woohyun2013-10-31.00:51:09
> hermet 2013-10-31.01:04:25
> leif 2013-10-31.02:50:45
> ryuan 2013-10-31.05:43:18
> cedric 2013-10-31.06:21:22
> seoz 2013-10-31.07:02:33
> antognolli 2013-10-31.07:09:28
> urandom2013-10-31.07:49:43
> tasn 2013-10-31.09:05:23
> devilhorns 2013-10-31.10:22:47
> raster 2013-10-31.11:03:46
> jeyzu 2013-10-31.11:13:21
> uartie 2013-10-31.11:45:41
> kuri 2013-10-31.13:08:38
>
> On 2013-10-31 12:33, Tom Hacohen wrote:
> > Well, suggest a list. I don't think we can easily automate that (as we
> > don't have last-login anymore). Gitolite might have logs.
> >
> > --
> > Tom.
> >
> > On 31/10/13 09:15, ChunEon Park wrote:
> >> I think it's time to clean up the committers who hasn't worked
> >> recently so far.
> >>
> >>
> >> -Regards, Hermet-
> >>
> >> -Original Message-
> >> From: "Luis Felipe Strano Moraes"
> >> To: ;
> >> Cc:
> >> Sent: 2013-10-30 (수) 02:19:04
> >> Subject: [EGIT] [admin/devs] master 01/01: dev--
> >>
> >> lfelipe pushed a commit to branch master.
> >>
> >>
> http://git.enlightenment.org/admin/devs.git/commit/?id=0c76c52eb1d45b5391c78e3eb1245f4321620556
> >>
> >> commit 0c76c52eb1d45b5391c78e3eb1245f4321620556
> >> Author: Luis Felipe Strano Moraes @gmail.com>
> >> Date: Tue Oct 29 15:17:10 2013 -0200
> >>
> >> dev--
> >>
> >> haven't been working on anything e-related recently
> >> ---
> >> lfelipe/id_rsa.pub 1 -
> >> lfelipe/info.txt9 -
> >> 2 files changed, 10 deletions(-)
> >>
> >> diff --git a/lfelipe/id_rsa.pub b/lfelipe/id_rsa.pub
> >> deleted file mode 100644
> >> index 0b6ee4d..000
> >> --- a/lfelipe/id_rsa.pub
> >> +++ /dev/null
> >> @@ -1 +0,0 @@
> >> -ssh-rsa
> >>
> B3NzaC1yc2EBIwAAAQEA1QDVDA+CkAJLbwS5OLi2Ts/DCbIpc0buzttvavnzRPs9mTb7Cf/fQg6uSoiXDKi0+acRUZ6
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
Here is the list of last *git write* access from enable users with that
some ugly script :
getent passwd \
| awk -F : '
{
if ($3 >= 1000 && $3 <= && $7 != "/sbin/nologin") {
print $1
}
}' \
| while read ; do
awk -v REPLY="${REPLY}" -v LAST=never '
{
if ($2 == REPLY && $4 = "git-receive-pack") {
LAST=$1
}
}
END {
print REPLY,LAST
}' /var/log/gitolite/gitolite-*.log
done \
| sort -k 2 | column -t
acidx never
aron never
ceolin never
dresb never
ewww never
fidencio never
gouachenever
incnever
kakaroto never
mello never
mickeylnever
monkeyiq never
morlenxus never
nash never
pespin never
playya never
raoul never
rfonseca never
ruinever
shorne never
sohyun never
turran never
vapier never
watchwolf never
xhell never
mej2013-03-25.09:48:07
andreas2013-05-18.04:52:14
gastal 2013-06-06.11:50:36
rakuco 2013-06-26.06:26:52
mekius 2013-07-08.17:22:09
thanatermesis 2013-08-02.06:32:06
tiago 2013-08-23.12:20:41
bdilly 2013-09-02.14:30:44
garik 2013-09-03.17:11:56
kimcinoo 2013-09-10.17:57:03
jypark 2013-09-12.01:43:39
jeffdameth 2013-10-02.14:26:17
princeamd 2013-10-03.05:35:25
mike_m 2013-10-06.15:02:43
quaker 2013-10-07.09:16:59
dorileo2013-10-15.13:29:13
asdfuser 2013-10-16.00:05:44
jaehwan2013-10-17.04:00:28
sanjeev2013-10-17.05:59:19
okra 2013-10-17.10:10:06
jihoon 2013-10-17.18:23:00
glima 2013-10-18.13:29:26
kiwi 2013-10-18.19:17:07
captainigloo 2013-10-18.21:54:23
kwo2013-10-19.10:36:26
billiob2013-10-20.03:45:11
illogict 2013-10-21.10:46:34
demarchi 2013-10-24.14:38:48
beber 2013-10-25.02:04:52
etrunko2013-10-25.18:36:25
stefan 2013-10-26.03:14:42
maxerba2013-10-26.03:41:45
onefang2013-10-26.08:22:49
jackdanielz2013-10-27.01:09:45
davemds2013-10-28.15:51:17
ravenlock 2013-10-28.18:54:29
ngc891 2013-10-29.03:30:26
hyoyoung 2013-10-29.07:55:17
zehortigoza2013-10-29.11:17:11
barbieri 2013-10-29.15:43:12
sung 2013-10-29.23:27:57
yakov 2013-10-30.02:52:25
ulisses2013-10-30.07:35:56
sachiel2013-10-30.11:02:33
kuuko 2013-10-30.12:02:57
discomfitor2013-10-30.14:25:55
yoz2013-10-30.17:04:55
jpeg 2013-10-30.18:12:46
englebass 2013-10-31.00:17:03
woohyun2013-10-31.00:51:09
hermet 2013-10-31.01:04:25
leif 2013-10-31.02:50:45
ryuan 2013-10-31.05:43:18
cedric 2013-10-31.06:21:22
seoz 2013-10-31.07:02:33
antognolli 2013-10-31.07:09:28
urandom2013-10-31.07:49:43
tasn 2013-10-31.09:05:23
devilhorns 2013-10-31.10:22:47
raster 2013-10-31.11:03:46
jeyzu 2013-10-31.11:13:21
uartie 2013-10-31.11:45:41
kuri 2013-10-31.13:08:38
On 2013-10-31 12:33, Tom Hacohen wrote:
> Well, suggest a list. I don't think we can easily automate that (as we
> don't have last-login anymore). Gitolite might have logs.
>
> --
> Tom.
>
> On 31/10/13 09:15, ChunEon Park wrote:
>> I think it's time to clean up the committers who hasn't worked
>> recently so far.
>>
>>
>> -Regards, Hermet-
>>
>> -Original Message-
>> From: "Luis Felipe Strano Moraes"
>> To: ;
>> Cc:
>> Sent: 2013-10-30 (수) 02:19:04
>> Subject: [EGIT] [admin/devs] master 01/01: dev--
>>
>> lfelipe pushed a commit to branch master.
>>
>> http://git.enlightenment.org/admin/devs.git/commit/?id=0c76c52eb1d45b5391c78e3eb1245f4321620556
>>
>> commit 0c76c52eb1d45b5391c78e3eb1245f4321620556
>> Author: Luis Felipe Strano Moraes @gmail.com>
>> Date: Tue Oct 29 15:17:10 2013 -0200
>>
>> dev--
>>
>> haven't been working on anything e-related recently
>> ---
>> lfelipe/id_rsa.pub 1 -
>> lfelipe/info.txt9 -
>> 2 files changed, 10 deletions(-)
>>
>> diff --git a/lfelipe/id_rsa.pub b/lfelipe/id_rsa.pub
>> deleted file mode 100644
>> index 0b6ee4d..000
>> --- a/lfelipe/id_rsa.pub
>> +++ /dev/null
>> @@ -1 +0,0 @@
>> -ssh-rsa
>> B3NzaC1yc2EBIwAAAQEA1QDVDA+CkAJLbwS5OLi2Ts/DCbIpc0buzttvavnzRPs9mTb7Cf/fQg6uSoiXDKi0+acRUZ6HMZW01/ACkLzrrcIvQnP/wqhvZICSTK5NR1cL562Z938M9IYkeJzkLWN5Ftk/hnuTu+c6OGVGfeT2lpz/34qPcgvewvXZ/dSgXP5IzRr/AfF5uOmsn5r30L6/t0HTWvK13wXbd17cl/Ls1/5DhzSBhqce7UHqfCdDSAOz/N/kQua/EMnFTelnKrcK3X8RTgA99DHJLDzQt8qneUkCz+OJgmavvHdtBxf5DOZl2VCSoXkAvyRyHGIozaii9rRr7u0HWZ2V5NKFAGqmuw==
>> lfelipe@annie
>> diff --git a/lfelipe/info.txt b/lfelipe/info.txt
>> deleted file mode 100644
>> in
[EGIT] [core/efl] master 01/01: Ok, This actually fixes maximized state properly now :) Basically, we still need to account for frame height, but not frame width when we are maximizing.
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=20f6676eb6ed0020c07272c9f59a20faf6ff651c
commit 20f6676eb6ed0020c07272c9f59a20faf6ff651c
Author: Chris Michael
Date: Thu Oct 31 17:21:33 2013 +
Ok, This actually fixes maximized state properly now :) Basically, we
still need to account for frame height, but not frame width when we
are maximizing.
Signed-off-by: Chris Michael
---
src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
index 7d3d444..4b99563 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
@@ -224,19 +224,20 @@ _ecore_evas_wl_common_cb_window_configure(void *data
EINA_UNUSED, int type EINA_
nw = ev->w;
nh = ev->h;
- if ((!ee->prop.maximized) && (!ee->prop.fullscreen))
+
+ if (!ee->prop.fullscreen)
{
int fw = 0, fh = 0;
evas_output_framespace_get(ee->evas, NULL, NULL, &fw, &fh);
if ((ee->rotation == 90) || (ee->rotation == 270))
{
- nw = ev->w - fh;
+ if (!ee->prop.maximized) nw = ev->w - fh;
nh = ev->h - fw;
}
else
{
- nw = ev->w - fw;
+ if (!ee->prop.maximized) nw = ev->w - fw;
nh = ev->h - fh;
}
}
--
[EGIT] [core/elementary] master 01/01: Add missing EINA_UNUSED to function params.
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=15b355a1195f0371c4e74d942ef9fcfa86a4a469
commit 15b355a1195f0371c4e74d942ef9fcfa86a4a469
Author: Chris Michael
Date: Thu Oct 31 17:05:17 2013 +
Add missing EINA_UNUSED to function params.
Signed-off-by: Chris Michael
---
src/lib/elm_win.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
index 12141c1..a1c15a5 100644
--- a/src/lib/elm_win.c
+++ b/src/lib/elm_win.c
@@ -2439,7 +2439,7 @@ _elm_win_frame_cb_close(void *data,
}
static void
-_elm_win_frame_obj_maximized(void *data, Evas_Object *obj, void *event)
+_elm_win_frame_obj_maximized(void *data, Evas_Object *obj EINA_UNUSED, void
*event EINA_UNUSED)
{
Elm_Win_Smart_Data *sd;
@@ -2448,7 +2448,7 @@ _elm_win_frame_obj_maximized(void *data, Evas_Object
*obj, void *event)
}
static void
-_elm_win_frame_obj_unmaximized(void *data, Evas_Object *obj, void *event)
+_elm_win_frame_obj_unmaximized(void *data, Evas_Object *obj EINA_UNUSED, void
*event EINA_UNUSED)
{
Elm_Win_Smart_Data *sd;
--
[EGIT] [core/elementary] master 01/01: Fix elm client applications to support maximize properly (ie: removing border shadow and resizing properly).
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=28763963bb9e26ea25ca182acc294c0a02f03ba2
commit 28763963bb9e26ea25ca182acc294c0a02f03ba2
Author: Chris Michael
Date: Thu Oct 31 17:00:23 2013 +
Fix elm client applications to support maximize properly (ie: removing
border shadow and resizing properly).
NB: Elm Theme needs fullscreen support old man !! :P
Signed-off-by: Chris Michael
---
src/lib/elm_win.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
index 95f4812..12141c1 100644
--- a/src/lib/elm_win.c
+++ b/src/lib/elm_win.c
@@ -2438,6 +2438,24 @@ _elm_win_frame_cb_close(void *data,
evas_object_unref(win);
}
+static void
+_elm_win_frame_obj_maximized(void *data, Evas_Object *obj, void *event)
+{
+ Elm_Win_Smart_Data *sd;
+
+ sd = data;
+ edje_object_signal_emit(sd->frame_obj, "elm,state,maximized", "elm");
+}
+
+static void
+_elm_win_frame_obj_unmaximized(void *data, Evas_Object *obj, void *event)
+{
+ Elm_Win_Smart_Data *sd;
+
+ sd = data;
+ edje_object_signal_emit(sd->frame_obj, "elm,state,unmaximized", "elm");
+}
+
static void
_elm_win_frame_add(Elm_Win_Smart_Data *sd,
const char *style)
@@ -2477,6 +2495,13 @@ _elm_win_frame_add(Elm_Win_Smart_Data *sd,
evas_object_event_callback_add
(sd->frame_obj, EVAS_CALLBACK_RESIZE, _elm_win_frame_obj_resize, sd);
+ /* FIXME: Elm Theme needs support for fullscreen state
+* (elm,state,fullscreen/unfullscreen) */
+ evas_object_smart_callback_add(sd->obj, SIG_MAXIMIZED,
+ _elm_win_frame_obj_maximized, sd);
+ evas_object_smart_callback_add(sd->obj, SIG_UNMAXIMIZED,
+ _elm_win_frame_obj_unmaximized, sd);
+
/* NB: Do NOT remove these calls !! Needed to calculate proper
* framespace on inital show of the window */
edje_object_size_min_calc(sd->frame_obj, &mw, &mh);
@@ -2536,6 +2561,11 @@ _elm_win_frame_del(Elm_Win_Smart_Data *sd)
evas_object_event_callback_del_full
(sd->frame_obj, EVAS_CALLBACK_RESIZE, _elm_win_frame_obj_resize, sd);
+evas_object_smart_callback_del(sd->obj, SIG_MAXIMIZED,
+ _elm_win_frame_obj_maximized);
+evas_object_smart_callback_del(sd->obj, SIG_UNMAXIMIZED,
+ _elm_win_frame_obj_unmaximized);
+
edje_object_signal_callback_del
(sd->frame_obj, "elm,action,move,start", "elm",
_elm_win_frame_cb_move_start);
--
[EGIT] [core/efl] master 01/01: Fix ecore_evas_wayland maximized support to function properly
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=c96cc485ab145f62a882597436ff7bc6155d0509
commit c96cc485ab145f62a882597436ff7bc6155d0509
Author: Chris Michael
Date: Thu Oct 31 16:58:21 2013 +
Fix ecore_evas_wayland maximized support to function properly
Previously, a "maximize" of an efl client would not actually resize to
the provided size as it would account for framespace width & height.
This fixes that so now "maximize" is Actually maximized.
Signed-off-by: Chris Michael
---
src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
index a40717e..7d3d444 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
@@ -217,15 +217,14 @@ _ecore_evas_wl_common_cb_window_configure(void *data
EINA_UNUSED, int type EINA_
if ((ee->x != ev->x) || (ee->y != ev->y))
{
-ee->req.x = ee->x;
-ee->req.y = ee->y;
+ee->req.x = ev->x;
+ee->req.y = ev->y;
if (ee->func.fn_move) ee->func.fn_move(ee);
}
nw = ev->w;
nh = ev->h;
-
- if ((ee->prop.maximized) || (!ee->prop.fullscreen))
+ if ((!ee->prop.maximized) && (!ee->prop.fullscreen))
{
int fw = 0, fh = 0;
--
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
On 31/10/13 16:33, Daniel Juyung Seo wrote: > On Thu, Oct 31, 2013 at 11:55 PM, Tom Hacohen wrote: > >> On 31/10/13 14:51, Carsten Haitzler (The Rasterman) wrote: >>> On Thu, 31 Oct 2013 11:33:25 + Tom Hacohen >> said: >>> Well, suggest a list. I don't think we can easily automate that (as we don't have last-login anymore). Gitolite might have logs. >>> >>> if someone wants to do it... fine - i was going to wait until we have >> our efl >>> 1.8/e18 etc. releases out of the way then we can do a bit of >> housekeeping. :) >> >> Yeah. I'm not doing it, but if Daniel wants to do it, I'm fine with that. >> :) >> >> > Which Daniel are you referring to? :) > I was referring to Hermet, AKA "the other Daniel". :) I thought you started the thread, didn't notice it was Hermet... -- Tom. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
On Thu, Oct 31, 2013 at 11:55 PM, Tom Hacohen wrote: > On 31/10/13 14:51, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 31 Oct 2013 11:33:25 + Tom Hacohen > said: > > > >> Well, suggest a list. I don't think we can easily automate that (as we > >> don't have last-login anymore). Gitolite might have logs. > > > > if someone wants to do it... fine - i was going to wait until we have > our efl > > 1.8/e18 etc. releases out of the way then we can do a bit of > housekeeping. :) > > Yeah. I'm not doing it, but if Daniel wants to do it, I'm fine with that. > :) > > Which Daniel are you referring to? :) Daniel Juyung Seo (SeoZ) > -- > Tom. > > > > -- > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eolian meta-data parsing
On 23/10/13 17:15, Leif Middelschulte wrote:
> Am 23.10.2013 um 01:54 schrieb Lucas De Marchi
> :
>
>> On Tue, Oct 22, 2013 at 3:03 PM, Leif Middelschulte
>> wrote:
>>> 2013/10/21 daniel.za...@samsung.com :
Hi all,
I would like to discuss about a project that we are beginning just now.
I presented it on EFL dev. day yesterday but I would like to share it
here since it will imply all the EFL developers (yes, you) one day or
another.
It is called Eolian and was first aimed to facilitate addition of new Eo
functions by auto-generating code. Then we noted that we can
automatically generate language bindings too but it is not the goal of
this discussion.
The idea is that each Eo class is represented into a .eo file. These
files are manually modified to add new functions, comments, callbacks...
and parsed and the generation phase updates the C/H files.
They contain descriptions of inherited classes, properties, methods,
base classes implemented functions and callbacks.
We thought about two formats:
- a C-like format:
Evas_Object_Image =
{
inherit
{
Evas_Object;
}
properties
{
/* Set the DPI resolution ... */
load_dpi(double dpi /* dpi resolution*/);
/* Apply the source object's clip to the proxy */
source_clip(Eina_Bool source_clip);
/* Set whether the image object's fill property ... */
filled(Eina_Bool filled);
/* Get the kind of looping the image object does. */
ro animated_loop_type(
Evas_Image_Animated_Loop_Hint hint /* hint */
);
/* Get the number times the animation of the object loops. */
ro animated_loop_count(
int loop_count
);
}
methods
{
/* Set the source object… */
source_set(
in Evas_Object* src /* in */,
out Eina_Bool* result /* out */
);
/* Get the current source object ... */
source_get(
out Evas_Object** src /* out */
);
/* Begin preloading an image … */
preload_begin();
/* Mark a sub-region of the given ... */
data_update_add(
in int x /* in */,
in int y /* in */,
in int w /* in */,
in int h /* in */
);
}
}
For C developers that we are, it has the advantage to be easier to our
eyes. It fits most of the needs but still lacks for specific points:
- if we have a property whose comment is different for set and get, how
can we describe it? By inserting "tokens" inside the comments
themselves, meaning parsing of the comments is needed.
- if we want to define a function as virtual pure, do we use the so
loved C++ notation "= 0"?
- properties that are read-only or write-only (only get or set): do we
add some ro/wo parameter, as in the example?
...
People complained that it seems too much like C++.
- JSON format:
{
"class_name" : "Evas_Object_Image",
"inherits" : [ "Evas_Object" ],
"properties" : [
{
"name" : "load_dpi",
"description" : "DPI resolution ...",
"parameter" : [
{
"name" : "dpi",
"type" : "double",
"description" : "dpi resolution"
}
}
... (don't have the force to write all ;-)
}
The format is less intuitive to C developers and there is more to write
but it is extensible and so easily solves the issues described in the
C-style.
So, until yesterday (the day I presented), I really thought we would go
on the C (ok, C++) style but now that I saw some faces when I showed the
C format and since I want to come back home safe, I prefer asking here.
Thank you for your help
JackDanielZ, alias Daniel Zomething
>>>
>>> Do you want something you'd only write in the text editor?
>>> If that's not a restriction, have you thought about using UML class
>>> diagrams? I'm not sure about inlining comments in it, but it has all
>>> the other features and is XML, so trivially transformable and
>>> validateable.
>>
>>
>> no
>>
> Okay, since my assumption: „We want to do it in a text editor“ seems to hold,
> I’d suggest having a look at Obj-C interface/class declarations, before
> coming up with yet another syntax/language.
> https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/DefiningClasses/DefiningClasses.html
> Obj-C is translated to ordinary C too. Maybe it would be interesting to have
> a look at the translator in gcc/clang and see whether it would fit our needs,
> if modified.
>
He's only talking about the @interface part here anyway. I don't see how
mimicing obj-c there would be any better than anything else. Especially
since obj-c has completely different function declaration syntax, and
that's the only part we'll be copying.
--
Tom.
[EGIT] [tools/exactness-edje-data] master 01/01: Also updated the box_001.png image.
tasn pushed a commit to branch master. http://git.enlightenment.org/tools/exactness-edje-data.git/commit/?id=f2418a74155fc256ad63717369d13fda71008a9e commit f2418a74155fc256ad63717369d13fda71008a9e Author: Tom Hacohen Date: Thu Oct 31 16:01:49 2013 + Also updated the box_001.png image. --- orig/box_001.png | Bin 2466 -> 2464 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/orig/box_001.png b/orig/box_001.png index ce1b28d..3791519 100644 Binary files a/orig/box_001.png and b/orig/box_001.png differ --
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 12:58 PM, Rafael Antognolli
wrote:
> On Thu, Oct 31, 2013 at 12:50 PM, Carsten Haitzler
> wrote:
>> On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL said:
>>
>>> On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
>>> wrote:
>>> > On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler
>>> > wrote:
>>> >> On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL
>>> >> said:
>>> >>> On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
>>> >>> wrote:
>>> >>> > On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
>>> >>> > wrote:
>>> >>> >> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
>>> >>> >> wrote:
>>> >>> >>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
>>> >>> >>> wrote:
>>> >>> Hey everyone,
>>> >>>
>>> >>> Our current API for setting a window as fullscreen does not support
>>> >>> specifying which output/display/monitor should be used as
>>> >>> fullscreen.
>>> >>> However, wayland does support it.
>>> >>>
>>> >>> Would it make sense to have such parameter in the fullscreen_set
>>> >>> API?
>>> >>> Or should it be a wayland-only API?
>>> >>> >>>
>>> >>> >>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
>>> >>> >>> NULL = unset */
>>> >>> >>>
>>> >>> >>> the current version remains and sets on current display.
>>> >>> >>> Alternatively
>>> >>> >>> we could just move the window to another display before making that
>>> >>> >>> fullscreen, no idea if this is okay.
>>> >>> >>
>>> >>> >> Yeah, current version sets on current display (the one where the
>>> >>> >> non-fullscreen window is already displayed), unless it's the first
>>> >>> >> time that the window is going to be displayed. Otherwise it will use
>>> >>> >> the first output. But that's up to the compositor to choose so far,
>>> >>> >> unless we explicitly specify which output to use.
>>> >>> >>
>>> >>> For the latter case, how would we do that? Maybe exposing an API
>>> >>> that
>>> >>> allows to set the "preferred" output, and then when fullscreen_set
>>> >>> is
>>> >>> called, it just uses that one?
>>> >>> >>>
>>> >>> >>> I'd say we need to make this in one go, unless we want some kind of
>>> >>> >>> general assignment to one display (not just for FS mode).
>>> >>> >>
>>> >>> >> OK...
>>> >>> >>
>>> >>> >>>
>>> >>> There's also a need to specify how the output should be referred
>>> >>> to.
>>> >>> Using an (unsigned) int, where 0 is the first output, 1 is the
>>> >>> second, etc? Or maybe allowing to specify something like "always
>>> >>> the
>>> >>> biggest one in area", or the widest one, or whatever... any
>>> >>> thoughts?
>>> >>> >>>
>>> >>> >>> We'd need a way to enumerate the displays (or whatever we call them,
>>> >>> >>> like zone, etc), they should return their properties such as size,
>>> >>> >>> position (?), capabilities (3d/stereo? color? what do we have here?)
>>> >>> >>> and some string to make it easy to debug.
>>> >>> >>>
>>> >>> >>> we have the handle to it, so it can be windowsystem agnostic
>>> >>> >>> (Display_ID *, which can be implemented differently for windows,
>>> >>> >>> x11,
>>> >>> >>> wayland...)
>>> >>> >>
>>> >>> >> So you are proposing that we change a good portion of our API to be
>>> >>> >> aware of multiple displays?
>>> >>> >>
>>> >>> >>>
>>> >>> That reminds me that we still have another problem. APIs such
>>> >>> ecore_wl_screen_size_get() return only the screen size of the first
>>> >>> monitor, not both.
>>> >>> >>>
>>> >>> >>> same as above, this should be based on current window (if there is a
>>> >>> >>> window handle) or the first one (if there is not, alterntively we
>>> >>> >>> can
>>> >>> >>> state it will refer to screen the mouse is over, but I guess this is
>>> >>> >>> incorrect and makes everything less predictable).
>>> >>> >>
>>> >>> >> Well, that API has no argument, so it just assumes the current
>>> >>> >> output.
>>> >>> >> For a given window, one could use ecore_evas_screen_geometry_get, and
>>> >>> >> that indeed will be attached to a given display, but only after the
>>> >>> >> Ecore_Evas has been shown first (at least on Wayland, if I'm not
>>> >>> >> wrong).
>>> >>> >>
>>> >>> What about a common API to select which output we are talking
>>> >>> about,
>>> >>> that must be called before any call that would refer to a specific
>>> >>> output? The problem with this is that it would make code very
>>> >>> wayland-specific :-/
>>> >>> >>>
>>> >>> >>> how so? just use the opaque handlers and abstract stuff in there.
>>> >>> >>
>>> >>> >> OK, so you suggestion is something like:
>>> >>> >>
>>> >>> >> Display {
>>> >>> >> ID;
>>> >>> >> size;
>>> >>> >> position; // might be some info from xrandr, like right-of another
>>> >>> >> display, etc, if that is even possible
>>> >>> >> capabilities (3d/stereo? color?)
>>> >>> >> dpi (I'm not even sure if we can
Re: [E-devel] Eolian meta-data parsing
On 21/10/13 18:29, daniel.za...@samsung.com wrote:
> Hi all,
>
> I would like to discuss about a project that we are beginning just now.
> I presented it on EFL dev. day yesterday but I would like to share it
> here since it will imply all the EFL developers (yes, you) one day or
> another.
>
> It is called Eolian and was first aimed to facilitate addition of new Eo
> functions by auto-generating code. Then we noted that we can
> automatically generate language bindings too but it is not the goal of
> this discussion.
>
> The idea is that each Eo class is represented into a .eo file. These
> files are manually modified to add new functions, comments, callbacks...
> and parsed and the generation phase updates the C/H files.
>
> They contain descriptions of inherited classes, properties, methods,
> base classes implemented functions and callbacks.
>
> We thought about two formats:
> - a C-like format:
> Evas_Object_Image =
> {
> inherit
> {
> Evas_Object;
> }
> properties
> {
> /* Set the DPI resolution ... */
> load_dpi(double dpi /* dpi resolution*/);
> /* Apply the source object's clip to the proxy */
> source_clip(Eina_Bool source_clip);
> /* Set whether the image object's fill property ... */
> filled(Eina_Bool filled);
> /* Get the kind of looping the image object does. */
> ro animated_loop_type(
> Evas_Image_Animated_Loop_Hint hint /* hint */
> );
> /* Get the number times the animation of the object loops. */
> ro animated_loop_count(
> int loop_count
> );
> }
> methods
> {
> /* Set the source object… */
> source_set(
> in Evas_Object* src /* in */,
> out Eina_Bool* result /* out */
> );
> /* Get the current source object ... */
> source_get(
> out Evas_Object** src /* out */
> );
> /* Begin preloading an image … */
> preload_begin();
> /* Mark a sub-region of the given ... */
> data_update_add(
> in int x /* in */,
> in int y /* in */,
> in int w /* in */,
> in int h /* in */
> );
> }
> }
>
> For C developers that we are, it has the advantage to be easier to our
> eyes. It fits most of the needs but still lacks for specific points:
> - if we have a property whose comment is different for set and get, how
> can we describe it? By inserting "tokens" inside the comments
> themselves, meaning parsing of the comments is needed.
> - if we want to define a function as virtual pure, do we use the so
> loved C++ notation "= 0"?
> - properties that are read-only or write-only (only get or set): do we
> add some ro/wo parameter, as in the example?
> ...
> People complained that it seems too much like C++.
>
> - JSON format:
> {
> "class_name" : "Evas_Object_Image",
> "inherits" : [ "Evas_Object" ],
> "properties" : [
> {
> "name" : "load_dpi",
> "description" : "DPI resolution ...",
> "parameter" : [
> {
> "name" : "dpi",
> "type" : "double",
> "description" : "dpi resolution"
> }
> }
> ... (don't have the force to write all ;-)
> }
> The format is less intuitive to C developers and there is more to write
> but it is extensible and so easily solves the issues described in the
> C-style.
>
> So, until yesterday (the day I presented), I really thought we would go
> on the C (ok, C++) style but now that I saw some faces when I showed the
> C format and since I want to come back home safe, I prefer asking here.
>
First of all, thank you Daniel for communicating your changes here. I
think that Eolian has the potential to be an important foundation in the
future of the EFL, so it's really important that it's good.
Haven't read the whole thread yet, but there are a few comments I have
to make:
1. A vote means nothing, we shouldn't go with something just because
people prefer one buzzword over the other.
2. As raster has said, saying "we also have the parser ready for this"
is like saying nothing. The "language" is in the strings themselves, not
the few delimiters.
I personally agree with raster, however I do prefer json in general. The
question is: can me make something that works for us with json? The
answer might be yes, might be no, needs to be evaluated, not arbitrarily
voted on.
Daniel: I think the main thing to see is how to make the best syntax.
C(++?)-style, json or whatever. I would prefer something that is already
well-defined like the structure that json provides, but maybe there
involve a C-like syntax, so something more like:
{
"class_name" : "Evas_Object_Image",
"inherits" : [ "Evas_Object" ],
"properties" : [
"load_dpi(double dpi)",
"source_clip(Eina_Bool source_clip)",
...
],
...
}
I'm not sure. I just think this should be discussed and evaluated as
it's of supreme importance. It should definitely not be overly cubersome
and complicated to work with, as that's what people will write in. Also,
it must support comments.
Let's figure this out. :)
--
Tom.
--
Android is increasing in popularity, but the open development platform that
developers love is al
[EGIT] [tools/exactness-edje-data] master 01/01: Updated images for the new Elm theme.
tasn pushed a commit to branch master. http://git.enlightenment.org/tools/exactness-edje-data.git/commit/?id=12854cda062eb8223577a1fedad41ea9539af192 commit 12854cda062eb8223577a1fedad41ea9539af192 Author: Tom Hacohen Date: Thu Oct 31 15:01:08 2013 + Updated images for the new Elm theme. --- orig/animations2_001.png | Bin 13276 -> 4141 bytes orig/basic2_001.png | Bin 26475 -> 8630 bytes orig/basic_001.png | Bin 7559 -> 636 bytes orig/box_001.png | Bin 7750 -> 2466 bytes orig/edje-nested_001.png | Bin 7886 -> 667 bytes orig/embryo_custom_state_002.png | Bin 18201 -> 18206 bytes orig/embryo_custom_state_003.png | Bin 18261 -> 18268 bytes orig/embryo_custom_state_004.png | Bin 18710 -> 18717 bytes orig/signals-messages_001.png| Bin 9715 -> 2137 bytes orig/signalsBubble_001.png | Bin 26475 -> 8630 bytes 10 files changed, 0 insertions(+), 0 deletions(-) diff --git a/orig/animations2_001.png b/orig/animations2_001.png index 4d8cfd0..813d831 100644 Binary files a/orig/animations2_001.png and b/orig/animations2_001.png differ diff --git a/orig/basic2_001.png b/orig/basic2_001.png index f15a86c..7705953 100644 Binary files a/orig/basic2_001.png and b/orig/basic2_001.png differ diff --git a/orig/basic_001.png b/orig/basic_001.png index 54c11bc..900366b 100644 Binary files a/orig/basic_001.png and b/orig/basic_001.png differ diff --git a/orig/box_001.png b/orig/box_001.png index 08549a4..ce1b28d 100644 Binary files a/orig/box_001.png and b/orig/box_001.png differ diff --git a/orig/edje-nested_001.png b/orig/edje-nested_001.png index 5e15d16..f645731 100644 Binary files a/orig/edje-nested_001.png and b/orig/edje-nested_001.png differ diff --git a/orig/embryo_custom_state_002.png b/orig/embryo_custom_state_002.png index 7624b09..c79077e 100644 Binary files a/orig/embryo_custom_state_002.png and b/orig/embryo_custom_state_002.png differ diff --git a/orig/embryo_custom_state_003.png b/orig/embryo_custom_state_003.png index feedf80..44c7f59 100644 Binary files a/orig/embryo_custom_state_003.png and b/orig/embryo_custom_state_003.png differ diff --git a/orig/embryo_custom_state_004.png b/orig/embryo_custom_state_004.png index 0c8b4cc..995c1be 100644 Binary files a/orig/embryo_custom_state_004.png and b/orig/embryo_custom_state_004.png differ diff --git a/orig/signals-messages_001.png b/orig/signals-messages_001.png index 1341a89..7150023 100644 Binary files a/orig/signals-messages_001.png and b/orig/signals-messages_001.png differ diff --git a/orig/signalsBubble_001.png b/orig/signalsBubble_001.png index f15a86c..7705953 100644 Binary files a/orig/signalsBubble_001.png and b/orig/signalsBubble_001.png differ --
Re: [E-devel] Eo API change and C++ binding
On 28/10/13 22:17, Felipe Magno de Almeida wrote:
> Hello all,
>
> I'm working on an Eo API change for EFL. We're working on top of
> Jérémy Zurcher's eo2 branch.
> The problem with creating Eo API with the current Eo or with eo2 is
> that information about a Eo class becomes inevatibly scattered and
> adds a lot of redudancy. For example in eo1 there's the need to write
> macros that check the signature, fill Eo_Op_Description array; for eo2
> there's the need to use the EO2_OP_FUNC_* macros to define the API
> functions, still fill Eo2_Op_Description array, cast the Private_Data,
> etc.
>
> We needed a way to create Eo classes that had more expressiveness. So
> that it becomes possible to read a Eo class and know how many
> functions it has, their signatures, etc (this is to create a C++
> binding generated by a tool, I'll get to this later).
>
> So we started working on a more expressive way to define Eo classes
> and we've implemented it. (Still lacks documentation and tests which
> are scheduled for november). The new API makes use of two sets of
> macros: EO3_DECLARE_* and EO3_DEFINE_*. These macros generate, through
> the CPP, the boilerplate code that is required for Eo classes, such as
> API functions (those that get called through eo2_do and route to the
> correct implementation function), event functions with specific
> signatures, etc.
>
> These macros declare and define the class, respectively, and are meant
> to be used in headers and .c files. These macros allow us to have a
> good expressiveness for defining Eo classes without moving away from C
> and while eliminating a lot of boilerplate code.
>
> So, one Eo class example using this API:
>
>
> https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo3_simple.h
>
> #define EO3_SIMPLE_CLASS eo3_simple \
> , constructor(simple_constructor, _constructor, int) \
> , destructor(_destructor)\
> , function(simple_inc, _inc, void) \
> , function(simple_get, _get, int)\
> , function(simple_set, _set, void, int) \
> , function(simple_virtual, _set, void, int) \
> , class_function(simple_class_foo, _class_hello, void, int) \
> , event(simple_set, int)
>
>
>
> https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo3_simple.c
>
> typedef struct
> {
> int x;
> } Private_Data;
>
> static void _inc(Eo *objid EINA_UNUSED, Private_Data* self)
> {
>printf("eo3_simple::inc %d->%d\n", self->x, self->x+1);
>self->x += 1;
> }
> static int _get(Eo *objid EINA_UNUSED, Private_Data* self)
> {
>printf("eo3_simple::get %d\n", self->x);
>return self->x;
> }
> static void _set(Eo *objid, Private_Data* self, int x)
> {
>eo2_do(objid, simple_set_callback_call(x));
>printf("eo3_simple::set %d\n", x);
>self->x = x;
> }
> // [ other functions ]
>
> EO3_DEFINE_CLASS(EO3_SIMPLE_CLASS, ((EO3_BASE_CLASS)), Private_Data)
>
> ===
>
> Which compared to eo2:
> https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo2_simple.c
> https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo2_simple.h
> Or eo1:
> https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo_simple.c
> https://github.com/expertisesolutions/efl/blob/eo3/eo2test/eo_simple.h
>
> Is much easier to use.
>
>
> Now to the C++ binding. This API modification to Eo is meant to make
> defining Eo classes expressive enough that a tool can be used to
> generate bindings automatically for other languages, specially C++.
>
> The tool that will generate the C++ binding will read the header files
> and with a CPP library it wil hook on EO3_DEFINE_* and EO3_DECLARE_*
> to read the class informations. This part of the tool will be written
> as a C++ library to be reused for other bindings to get the necessary
> information for the EFL API through its headers.
>
> Eolian is also being developed by JackDanielZ that gives
> expressiveness for defining Eo classes by using another language and
> tool that generates the headers and C files. The C++ binding
> generating tool can easily be made to read both formats to generate
> the binding.
>
> However, I feel that this Eo API modification has its merits for
> whoever might want to use C directly to develop in EFL which I think
> is a great plus and here I'm advocating that this goes upstream so we
> can go forward with a C++ binding for EFL.
>
> There are other examples of the API in
> https://github.com/expertisesolutions/efl/tree/eo3/eo2test . All files
> that start with eo3_*.
>
> Also, we have the examples that specify how the C++ generated binding
> tool will output the generated files from this EO API (or the .eo
> files) at
> https://github.com/expertisesolutions/efl/tree/eo3/eo2test/cxx/generated
> with usage samples at
> https://github.com/expertisesolutions/efl/tree/eo3/eo2test/cxx/sa
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
On 31/10/13 14:51, Carsten Haitzler (The Rasterman) wrote: > On Thu, 31 Oct 2013 11:33:25 + Tom Hacohen said: > >> Well, suggest a list. I don't think we can easily automate that (as we >> don't have last-login anymore). Gitolite might have logs. > > if someone wants to do it... fine - i was going to wait until we have our efl > 1.8/e18 etc. releases out of the way then we can do a bit of housekeeping. :) Yeah. I'm not doing it, but if Daniel wants to do it, I'm fine with that. :) -- Tom. -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 12:50 PM, Carsten Haitzler wrote:
> On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL said:
>
>> On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
>> wrote:
>> > On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler
>> > wrote:
>> >> On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL said:
>> >>> On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
>> >>> wrote:
>> >>> > On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
>> >>> > wrote:
>> >>> >> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
>> >>> >> wrote:
>> >>> >>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
>> >>> >>> wrote:
>> >>> Hey everyone,
>> >>>
>> >>> Our current API for setting a window as fullscreen does not support
>> >>> specifying which output/display/monitor should be used as
>> >>> fullscreen.
>> >>> However, wayland does support it.
>> >>>
>> >>> Would it make sense to have such parameter in the fullscreen_set
>> >>> API?
>> >>> Or should it be a wayland-only API?
>> >>> >>>
>> >>> >>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
>> >>> >>> NULL = unset */
>> >>> >>>
>> >>> >>> the current version remains and sets on current display.
>> >>> >>> Alternatively
>> >>> >>> we could just move the window to another display before making that
>> >>> >>> fullscreen, no idea if this is okay.
>> >>> >>
>> >>> >> Yeah, current version sets on current display (the one where the
>> >>> >> non-fullscreen window is already displayed), unless it's the first
>> >>> >> time that the window is going to be displayed. Otherwise it will use
>> >>> >> the first output. But that's up to the compositor to choose so far,
>> >>> >> unless we explicitly specify which output to use.
>> >>> >>
>> >>> For the latter case, how would we do that? Maybe exposing an API
>> >>> that
>> >>> allows to set the "preferred" output, and then when fullscreen_set
>> >>> is
>> >>> called, it just uses that one?
>> >>> >>>
>> >>> >>> I'd say we need to make this in one go, unless we want some kind of
>> >>> >>> general assignment to one display (not just for FS mode).
>> >>> >>
>> >>> >> OK...
>> >>> >>
>> >>> >>>
>> >>> There's also a need to specify how the output should be referred to.
>> >>> Using an (unsigned) int, where 0 is the first output, 1 is the
>> >>> second, etc? Or maybe allowing to specify something like "always the
>> >>> biggest one in area", or the widest one, or whatever... any
>> >>> thoughts?
>> >>> >>>
>> >>> >>> We'd need a way to enumerate the displays (or whatever we call them,
>> >>> >>> like zone, etc), they should return their properties such as size,
>> >>> >>> position (?), capabilities (3d/stereo? color? what do we have here?)
>> >>> >>> and some string to make it easy to debug.
>> >>> >>>
>> >>> >>> we have the handle to it, so it can be windowsystem agnostic
>> >>> >>> (Display_ID *, which can be implemented differently for windows, x11,
>> >>> >>> wayland...)
>> >>> >>
>> >>> >> So you are proposing that we change a good portion of our API to be
>> >>> >> aware of multiple displays?
>> >>> >>
>> >>> >>>
>> >>> That reminds me that we still have another problem. APIs such
>> >>> ecore_wl_screen_size_get() return only the screen size of the first
>> >>> monitor, not both.
>> >>> >>>
>> >>> >>> same as above, this should be based on current window (if there is a
>> >>> >>> window handle) or the first one (if there is not, alterntively we can
>> >>> >>> state it will refer to screen the mouse is over, but I guess this is
>> >>> >>> incorrect and makes everything less predictable).
>> >>> >>
>> >>> >> Well, that API has no argument, so it just assumes the current output.
>> >>> >> For a given window, one could use ecore_evas_screen_geometry_get, and
>> >>> >> that indeed will be attached to a given display, but only after the
>> >>> >> Ecore_Evas has been shown first (at least on Wayland, if I'm not
>> >>> >> wrong).
>> >>> >>
>> >>> What about a common API to select which output we are talking about,
>> >>> that must be called before any call that would refer to a specific
>> >>> output? The problem with this is that it would make code very
>> >>> wayland-specific :-/
>> >>> >>>
>> >>> >>> how so? just use the opaque handlers and abstract stuff in there.
>> >>> >>
>> >>> >> OK, so you suggestion is something like:
>> >>> >>
>> >>> >> Display {
>> >>> >> ID;
>> >>> >> size;
>> >>> >> position; // might be some info from xrandr, like right-of another
>> >>> >> display, etc, if that is even possible
>> >>> >> capabilities (3d/stereo? color?)
>> >>> >> dpi (I'm not even sure if we can query different DPIs for different
>> >>> >> monitors, but I've seen discussion about future work on this on
>> >>> >> Wayland);
>> >>> >> }
>> >>> >>
>> >>> >> And then change/add some APIs to refer to a specific display when
>> >>> >> setting things?
>>
Re: [E-devel] [e-users] Is there *real* documentation for edje?
On Thu, 31 Oct 2013 09:02:04 -0300 Vinícius dos Santos Oliveira said: > Em Qui, 2013-10-31 às 08:51 +0900, Carsten Haitzler escreveu: > > > i know. i spent some of my early life on unix/linux paying large sums > > for > > o'reilly books. and reading them cover to cover. they had diagrams. i > > frankly > > far prefer raw simple code over those books. the code is digestible in > > a > > fraction of the time. :) if i have an actual working bit of code i can > > compile > > it, run it and then modify it to see how it wobbles when poked. poke a > > bit more > > and see some more wobbling. these wobbles tell me the story of how > > CHANGES to > > the example affect the behaviour. start small with small changes and > > see. :) a > > book doesn't give me that. english words don't give me that. code > > does. :) but > > that is my style - i know that within all fields of education > > including foreign > > languages, math, science, etc. etc. i always gravitated to "learn by > > example". > > i naturally break up the examples into their constituent parts and > > know how to > > manipulate them - the pattern builds over time naturally. > > > Code is interactive. School and all non-interactive shit is difficult > and pain to learn (at least for me and for you). > > But... I wonder how you avoid undefined behaviour code that can break in > the next release of the lib/compiler or in the second compiler/platform. experience teaches... and of course reading docs/references. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, 31 Oct 2013 22:53:37 +0900 Cedric BAIL said:
> On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
> wrote:
> > On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler
> > wrote:
> >> On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL said:
> >>> On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
> >>> wrote:
> >>> > On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
> >>> > wrote:
> >>> >> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
> >>> >> wrote:
> >>> >>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
> >>> >>> wrote:
> >>> Hey everyone,
> >>>
> >>> Our current API for setting a window as fullscreen does not support
> >>> specifying which output/display/monitor should be used as fullscreen.
> >>> However, wayland does support it.
> >>>
> >>> Would it make sense to have such parameter in the fullscreen_set API?
> >>> Or should it be a wayland-only API?
> >>> >>>
> >>> >>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
> >>> >>> NULL = unset */
> >>> >>>
> >>> >>> the current version remains and sets on current display. Alternatively
> >>> >>> we could just move the window to another display before making that
> >>> >>> fullscreen, no idea if this is okay.
> >>> >>
> >>> >> Yeah, current version sets on current display (the one where the
> >>> >> non-fullscreen window is already displayed), unless it's the first
> >>> >> time that the window is going to be displayed. Otherwise it will use
> >>> >> the first output. But that's up to the compositor to choose so far,
> >>> >> unless we explicitly specify which output to use.
> >>> >>
> >>> For the latter case, how would we do that? Maybe exposing an API that
> >>> allows to set the "preferred" output, and then when fullscreen_set is
> >>> called, it just uses that one?
> >>> >>>
> >>> >>> I'd say we need to make this in one go, unless we want some kind of
> >>> >>> general assignment to one display (not just for FS mode).
> >>> >>
> >>> >> OK...
> >>> >>
> >>> >>>
> >>> There's also a need to specify how the output should be referred to.
> >>> Using an (unsigned) int, where 0 is the first output, 1 is the
> >>> second, etc? Or maybe allowing to specify something like "always the
> >>> biggest one in area", or the widest one, or whatever... any thoughts?
> >>> >>>
> >>> >>> We'd need a way to enumerate the displays (or whatever we call them,
> >>> >>> like zone, etc), they should return their properties such as size,
> >>> >>> position (?), capabilities (3d/stereo? color? what do we have here?)
> >>> >>> and some string to make it easy to debug.
> >>> >>>
> >>> >>> we have the handle to it, so it can be windowsystem agnostic
> >>> >>> (Display_ID *, which can be implemented differently for windows, x11,
> >>> >>> wayland...)
> >>> >>
> >>> >> So you are proposing that we change a good portion of our API to be
> >>> >> aware of multiple displays?
> >>> >>
> >>> >>>
> >>> That reminds me that we still have another problem. APIs such
> >>> ecore_wl_screen_size_get() return only the screen size of the first
> >>> monitor, not both.
> >>> >>>
> >>> >>> same as above, this should be based on current window (if there is a
> >>> >>> window handle) or the first one (if there is not, alterntively we can
> >>> >>> state it will refer to screen the mouse is over, but I guess this is
> >>> >>> incorrect and makes everything less predictable).
> >>> >>
> >>> >> Well, that API has no argument, so it just assumes the current output.
> >>> >> For a given window, one could use ecore_evas_screen_geometry_get, and
> >>> >> that indeed will be attached to a given display, but only after the
> >>> >> Ecore_Evas has been shown first (at least on Wayland, if I'm not
> >>> >> wrong).
> >>> >>
> >>> What about a common API to select which output we are talking about,
> >>> that must be called before any call that would refer to a specific
> >>> output? The problem with this is that it would make code very
> >>> wayland-specific :-/
> >>> >>>
> >>> >>> how so? just use the opaque handlers and abstract stuff in there.
> >>> >>
> >>> >> OK, so you suggestion is something like:
> >>> >>
> >>> >> Display {
> >>> >> ID;
> >>> >> size;
> >>> >> position; // might be some info from xrandr, like right-of another
> >>> >> display, etc, if that is even possible
> >>> >> capabilities (3d/stereo? color?)
> >>> >> dpi (I'm not even sure if we can query different DPIs for different
> >>> >> monitors, but I've seen discussion about future work on this on
> >>> >> Wayland);
> >>> >> }
> >>> >>
> >>> >> And then change/add some APIs to refer to a specific display when
> >>> >> setting things?
> >>> >
> >>> > change is impossible at this time (abi/api stability) and cumbersome
> >>> > for most apps that don't care.
> >>>
> >>> Indeed.
> >>>
> >>> > then we must add new apis for those apps that care (ie: a presentation
> >>> > tool
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
On Thu, 31 Oct 2013 21:41:20 +0900 Daniel Juyung Seo said: > On Thu, Oct 31, 2013 at 8:33 PM, Tom Hacohen wrote: > > > Well, suggest a list. I don't think we can easily automate that (as we > > don't have last-login anymore). Gitolite might have logs. > > > > > Well we did this kind of clean up around 2 years ago if I remember > correctly. > But I don't remember how we did it. > What I remember is we did a *last call* at that time to give a last chance > for some devs to keep the commit access. i went thru the svn logs and simply looked at the last time a developer committed something i think i made it if they committed last more than 12 months ago - put them on the "remove access" list - thus the call for them to reply and say they need their access. > > -- > > Tom. > > > > On 31/10/13 09:15, ChunEon Park wrote: > > > I think it's time to clean up the committers who hasn't worked recently > > so far. > > > > I totally agree with this. I thought the same :) > > Daniel Juyung Seo (SeoZ) > > > > > > > > > > > -Regards, Hermet- > > > > > > -Original Message- > > > From: "Luis Felipe Strano Moraes" > > > To: ; > > > Cc: > > > Sent: 2013-10-30 (수) 02:19:04 > > > Subject: [EGIT] [admin/devs] master 01/01: dev-- > > > > > > lfelipe pushed a commit to branch master. > > > > > > > > http://git.enlightenment.org/admin/devs.git/commit/?id=0c76c52eb1d45b5391c78e3eb1245f4321620556 > > > > > > commit 0c76c52eb1d45b5391c78e3eb1245f4321620556 > > > Author: Luis Felipe Strano Moraes @gmail.com> > > > Date: Tue Oct 29 15:17:10 2013 -0200 > > > > > > dev-- > > > > > > haven't been working on anything e-related recently > > > --- > > > lfelipe/id_rsa.pub 1 - > > > lfelipe/info.txt9 - > > > 2 files changed, 10 deletions(-) > > > > > > diff --git a/lfelipe/id_rsa.pub b/lfelipe/id_rsa.pub > > > deleted file mode 100644 > > > index 0b6ee4d..000 > > > --- a/lfelipe/id_rsa.pub > > > +++ /dev/null > > > @@ -1 +0,0 @@ > > > -ssh-rsa > > B3NzaC1yc2EBIwAAAQEA1QDVDA > > +CkAJLbwS5OLi2Ts/DCbIpc0buzttvavnzRPs9mTb7Cf/fQg6uSoiXDKi0 > > +acRUZ6HMZW01/ACkLzrrcIvQnP/wqhvZICSTK5NR1cL562Z938M9IYkeJzkLWN5Ftk/hnuTu > > +c6OGVGfeT2lpz/34qPcgvewvXZ/dSgXP5IzRr/AfF5uOmsn5r30L6/t0HTWvK13wXbd17cl/Ls1/5DhzSBhqce7UHqfCdDSAOz/N/kQua/EMnFTelnKrcK3X8RTgA99DHJLDzQt8qneUkCz > > +OJgmavvHdtBxf5DOZl2VCSoXkAvyRyHGIozaii9rRr7u0HWZ2V5NKFAGqmuw== > > lfelipe@annie > > > diff --git a/lfelipe/info.txt b/lfelipe/info.txt > > > deleted file mode 100644 > > > index 3fc8d81..000 > > > --- a/lfelipe/info.txt > > > +++ /dev/null > > > @@ -1,9 +0,0 @@ > > > -Login:lfelipe > > > -IRC Nick: lfelipe > > > -Cloak:developer/lfelipe > > > -Name: Luis Felipe Strano Moraes > > > -Location: Campinas, Brazil > > > -E-Mail: -lfel...@profusion.mobi > > > -Contributing: Evas, Ecore, Edje, Epsilon, Efreet > > > -Group:Libraries > > > -Platform: Ubuntu (Linux) > > > > > > > > > > > > > -- > > Android is increasing in popularity, but the open development platform that > > developers love is also attractive to malware creators. Download this white > > paper to learn more about secure code signing practices that can help keep > > Android apps secure. > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > -- > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
On Thu, 31 Oct 2013 11:33:25 + Tom Hacohen said: > Well, suggest a list. I don't think we can easily automate that (as we > don't have last-login anymore). Gitolite might have logs. if someone wants to do it... fine - i was going to wait until we have our efl 1.8/e18 etc. releases out of the way then we can do a bit of housekeeping. :) > -- > Tom. > > On 31/10/13 09:15, ChunEon Park wrote: > > I think it's time to clean up the committers who hasn't worked recently so > > far. > > > > > > -Regards, Hermet- > > > > -Original Message- > > From: "Luis Felipe Strano Moraes" > > To: ; > > Cc: > > Sent: 2013-10-30 (수) 02:19:04 > > Subject: [EGIT] [admin/devs] master 01/01: dev-- > > > > lfelipe pushed a commit to branch master. > > > > http://git.enlightenment.org/admin/devs.git/commit/?id=0c76c52eb1d45b5391c78e3eb1245f4321620556 > > > > commit 0c76c52eb1d45b5391c78e3eb1245f4321620556 > > Author: Luis Felipe Strano Moraes @gmail.com> > > Date: Tue Oct 29 15:17:10 2013 -0200 > > > > dev-- > > > > haven't been working on anything e-related recently > > --- > > lfelipe/id_rsa.pub 1 - > > lfelipe/info.txt9 - > > 2 files changed, 10 deletions(-) > > > > diff --git a/lfelipe/id_rsa.pub b/lfelipe/id_rsa.pub > > deleted file mode 100644 > > index 0b6ee4d..000 > > --- a/lfelipe/id_rsa.pub > > +++ /dev/null > > @@ -1 +0,0 @@ > > -ssh-rsa B3NzaC1yc2EBIwAAAQEA1QDVDA > > +CkAJLbwS5OLi2Ts/DCbIpc0buzttvavnzRPs9mTb7Cf/fQg6uSoiXDKi0 > > +acRUZ6HMZW01/ACkLzrrcIvQnP/wqhvZICSTK5NR1cL562Z938M9IYkeJzkLWN5Ftk/hnuTu > > +c6OGVGfeT2lpz/34qPcgvewvXZ/dSgXP5IzRr/AfF5uOmsn5r30L6/t0HTWvK13wXbd17cl/Ls1/5DhzSBhqce7UHqfCdDSAOz/N/kQua/EMnFTelnKrcK3X8RTgA99DHJLDzQt8qneUkCz > > +OJgmavvHdtBxf5DOZl2VCSoXkAvyRyHGIozaii9rRr7u0HWZ2V5NKFAGqmuw== > > lfelipe@annie diff --git a/lfelipe/info.txt b/lfelipe/info.txt deleted file > > mode 100644 index 3fc8d81..000 > > --- a/lfelipe/info.txt > > +++ /dev/null > > @@ -1,9 +0,0 @@ > > -Login:lfelipe > > -IRC Nick: lfelipe > > -Cloak:developer/lfelipe > > -Name: Luis Felipe Strano Moraes > > -Location: Campinas, Brazil > > -E-Mail: -lfel...@profusion.mobi > > -Contributing: Evas, Ecore, Edje, Epsilon, Efreet > > -Group:Libraries > > -Platform: Ubuntu (Linux) > > > > > > -- > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/elementary] master 01/02: sync elm theme with e17 theme changes made.
raster pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=88d7ebc6fd1161d7975f3b6dd3e400e867c691a9
commit 88d7ebc6fd1161d7975f3b6dd3e400e867c691a9
Author: Carsten Haitzler (Rasterman)
Date: Thu Oct 31 22:19:03 2013 +0900
sync elm theme with e17 theme changes made.
---
data/themes/edc/battery.edc | 2 ++
data/themes/edc/music_control.edc | 55 ---
2 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/data/themes/edc/battery.edc b/data/themes/edc/battery.edc
index d190376..3ef55a5 100644
--- a/data/themes/edc/battery.edc
+++ b/data/themes/edc/battery.edc
@@ -224,6 +224,7 @@ group { name: "e/modules/battery/main";
color_class: "module_label";
text { font: "Sans"; size: 6;
min: 0 1;
+ fit: 1 1;
text_class: "module_small";
}
}
@@ -242,6 +243,7 @@ group { name: "e/modules/battery/main";
color_class: "module_label";
text { font: "Sans"; size: 6;
min: 0 1;
+ fit: 1 1;
text_class: "module_small";
}
}
diff --git a/data/themes/edc/music_control.edc
b/data/themes/edc/music_control.edc
index f00d243..bdf3cb7 100644
--- a/data/themes/edc/music_control.edc
+++ b/data/themes/edc/music_control.edc
@@ -29,6 +29,14 @@ group { name: "modules/music-control/popup";
images.image: "icon_next.png" COMP;
images.image: "icon_pause.png" COMP;
images.image: "icon_play.png" COMP;
+ styles {
+ style { name: "music_control_metadata_style";
+ base: "font="FN" font_size=10 align=left text_class=tb_plain
color=# style=shadow,bottom shadow_color=#0080";
+ tag: "title" "+ font_size=12 font="FNBD" text_class=tb_big";
+ tag: "tag" "+ font_size=8 color=#888f";
+ tag: "br" "\n";
+ }
+ }
script {
public message(Msg_Type:type, id, ...) {
new txt[128];
@@ -37,31 +45,57 @@ group { name: "modules/music-control/popup";
}
}
parts {
+ part { name: "cover_bg";
+ description { state: "default" 0;
+min: 90 90;
+rel1.relative: 0.0 0.0;
+rel2.relative: 0.35 1.0;
+image.normal: "music_control_icon.png";
+ }
+ }
+ part { name: "cover_swallow"; type: SWALLOW;
+ description { state: "default" 0;
+rel1.to: "cover_bg";
+rel2.to: "cover_bg";
+ }
+ }
part { name: "player_name"; type: TEXT;
description { state: "default" 0;
text.size: 12;
text.text: "Music player";
text.font: FN;
-rel1.relative: 0.0 0.0;
+rel1.relative: 1.0 0.0;
rel2.relative: 1.0 0.0;
-rel2.offset: 0 16;
+rel2.offset: 0 12;
}
}
- part { name: "previous_btn";
+ part { name: "metadata"; type: TEXTBLOCK;
description { state: "default" 0;
-aspect: 1.0 1.0; aspect_preference: BOTH;
+text {
+ style: "music_control_metadata_style";
+ text: "Song Title";
+ align: 0.0 0.0;
+}
rel1.to: "player_name";
rel1.relative: 0.0 1.0;
-rel2.relative: 0.33 1.0;
+rel1.offset: 3 0;
+ }
+ }
+ part { name: "previous_btn";
+ description { state: "default" 0;
+max: 32 32;
+aspect: 1.0 1.0; aspect_preference: BOTH;
+align: 0.1 1.0;
+rel1.relative: 0.35 0.0;
image.normal: "icon_prev.png";
}
}
part { name: "play_btn";
description { state: "default" 0;
+max: 32 32;
aspect: 1.0 1.0; aspect_preference: BOTH;
-rel1.to: "player_name";
-rel1.relative: 0.33 1.0;
-rel2.relative: 0.66 1.0;
+align: 0.5 1.0;
+rel1.relative: 0.35 0.0;
image.normal: "icon_pause.png";
}
description { state: "play" 0.0;
@@ -71,10 +105,11 @@ group { name: "modules/music-control/popup";
}
part { name: "next_btn";
description { state: "default" 0;
+max: 32 32;
aspect: 1.0 1.0; aspect_preference: BOTH;
+align: 0.9 1.0;
+rel1.relative: 0.35 0.0;
rel1.to: "player_name";
-rel1.relative: 0.66 1.0;
-rel2.relative: 1.0 1.0;
image.normal: "icon_next.png";
}
}
--
[EGIT] [core/enlightenment] master 01/03: module version sanity check -> make sure module versions match EXACTLY.
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=7f78ae9e53b1548f372e476e0b61967630f96f64
commit 7f78ae9e53b1548f372e476e0b61967630f96f64
Author: Carsten Haitzler (Rasterman)
Date: Wed Oct 30 12:07:42 2013 +0900
module version sanity check -> make sure module versions match EXACTLY.
if compile time headers (module version) does not match e's version
then modules likely may fail; to work right - so make sure they match
exactly (for release purposes)
---
src/bin/e_module.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/bin/e_module.c b/src/bin/e_module.c
index aa92878..9b9041a 100644
--- a/src/bin/e_module.c
+++ b/src/bin/e_module.c
@@ -351,11 +351,11 @@ e_module_new(const char *name)
m->error = 1;
goto init_done;
}
- if (m->api->version < E_MODULE_API_VERSION)
+ if (m->api->version != E_MODULE_API_VERSION)
{
snprintf(body, sizeof(body),
_("Module API ErrorError initializing Module: %s"
- "It requires a minimum module API version of: %i."
+ "It requires a module API version of: %i."
"The module API advertized by Enlightenment is: %i."),
_(m->api->name), m->api->version, E_MODULE_API_VERSION);
--
[EGIT] [core/enlightenment] master 02/03: make emotion as well as elm requirements, ecore-imf is not used anymore.
raster pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=6eca480e761447fc18e1b7e576658dcb1f969671
commit 6eca480e761447fc18e1b7e576658dcb1f969671
Author: Carsten Haitzler (Rasterman)
Date: Thu Oct 31 16:58:26 2013 +0900
make emotion as well as elm requirements, ecore-imf is not used anymore.
---
configure.ac | 53 ++--
src/bin/Makefile.am | 4 +--
src/bin/e_main.c | 28 ++---
src/bin/e_widget_filepreview.c | 10 +---
src/bin/e_win.c | 11 -
src/modules/Makefile_conf2.am| 4 +--
src/modules/Makefile_teamwork.am | 6 ++---
src/modules/teamwork/e_mod_tw.c | 24 +-
8 files changed, 17 insertions(+), 123 deletions(-)
diff --git a/configure.ac b/configure.ac
index 06eabd3..d86e216 100644
--- a/configure.ac
+++ b/configure.ac
@@ -533,6 +533,8 @@ PKG_CHECK_MODULES(E, [
eina >= ${efl_version}
eldbus >= ${efl_version}
eio >= ${efl_version}
+ elementary >= ${efl_version}
+ emotion >= ${efl_version}
$eeze_mount
$udisks_mount
$device_backend
@@ -551,51 +553,14 @@ efreet >= ${efl_version} \
efreet-mime >= ${efl_version} \
efreet-trash >= ${efl_version} \
eina >= ${efl_version} \
-eldbus \
+eldbus >= ${efl_version} \
eio >= ${efl_version} \
+elementary >= ${efl_version} \
+emotion >= ${efl_version} \
$udisks_mount \
$eeze_mount \
$device_backend"
-
-want_elementary=auto
-have_elementary=no
-AC_ARG_ENABLE(elementary,
- AC_HELP_STRING([--enable-elementary], [enable Elementary support
@<:@default=detect@:>@]),
- [want_elementary=$enableval],
- [want_elementary=auto]
-)
-if test "x$want_elementary" != "xno"; then
- PKG_CHECK_MODULES(ELM, [elementary >= ${efl_version}],
- [have_elementary=yes], [have_elementary=no])
- if test "x$want_elementary" = "xyes" -a "x$have_elementary" = "xno"; then
- AC_MSG_ERROR([Elementary support requested but it was not found])
- fi
- if test "x$have_elementary" = "xyes"; then
- AC_DEFINE([HAVE_ELEMENTARY], 1, "Have Elementary support")
- requirements_e="${requirements_e} elementary > 1.6.9.0"
- fi
-fi
-
-want_emotion=auto
-have_emotion=no
-AC_ARG_ENABLE(emotion,
- AC_HELP_STRING([--enable-emotion], [enable emotion support
@<:@default=detect@:>@]),
- [want_emotion=$enableval],
- [want_emotion=auto]
-)
-if test "x$want_emotion" != "xno"; then
- PKG_CHECK_MODULES(EMOTION, [emotion >= ${efl_version}],
- [have_emotion=yes], [have_emotion=no])
- if test "x$want_emotion" = "xyes" -a "x$have_emotion" = "xno"; then
- AC_MSG_ERROR([emotion support requested but it was not found])
- fi
- if test "x$have_emotion" = "xyes"; then
- AC_DEFINE([HAVE_EMOTION], 1, "Have emotion support")
- requirements_e="${requirements_e} emotion >= ${efl_version}"
- fi
-fi
-
PKG_CHECK_MODULES(E_OPEN, [
eina >= ${efl_version}
ecore >= ${efl_version}
@@ -603,10 +568,8 @@ PKG_CHECK_MODULES(E_OPEN, [
efreet-mime >= ${efl_version}
])
-AC_E_CHECK_PKG(ECORE_IMF, [ ecore-imf >= ${efl_version} ecore-imf-evas >=
${efl_version} ], [], [:])
-
-e_libs="$E_LIBS $LIBINTL $fnmatch_libs $ECORE_IMF_LIBS $execinfo_libs"
-e_cflags="-DUSE_E_CONFIG_H $E_CFLAGS $ECORE_IMF_CFLAGS"
+e_libs="$E_LIBS $LIBINTL $fnmatch_libs $execinfo_libs"
+e_cflags="-DUSE_E_CONFIG_H $E_CFLAGS"
e_configflags="-DUSE_E_CONFIG_H"
AC_SUBST(e_libs)
@@ -894,7 +857,7 @@ AC_E_OPTIONAL_MODULE([fileman], true)
AC_E_OPTIONAL_MODULE([fileman_opinfo], true)
AC_E_OPTIONAL_MODULE([wizard], true)
AC_E_OPTIONAL_MODULE([conf], true)
-AC_E_OPTIONAL_MODULE([conf2], $have_elementary)
+AC_E_OPTIONAL_MODULE([conf2], true)
AC_E_OPTIONAL_MODULE([conf_comp], true)
AC_E_OPTIONAL_MODULE([conf_wallpaper2], true)
AC_E_OPTIONAL_MODULE([conf_theme], true, true)
diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am
index 7717312..92110bd 100644
--- a/src/bin/Makefile.am
+++ b/src/bin/Makefile.am
@@ -12,8 +12,6 @@ AM_CPPFLAGS = \
@cf_cflags@ \
@VALGRIND_CFLAGS@ \
@EDJE_DEF@ \
-@ELM_CFLAGS@ \
-@EMOTION_CFLAGS@ \
@WAYLAND_CFLAGS@ \
@WAYLAND_EGL_CFLAGS@ \
-DE_BINDIR=\"$(bindir)\" \
@@ -386,7 +384,7 @@ e_main.c \
$(enlightenment_src)
enlightenment_LDFLAGS = -export-dynamic
-enlightenment_LDADD = @e_libs@ @ELM_LIBS@ @EMOTION_LIBS@ @dlopen_libs@
@cf_libs@ @VALGRIND_LIBS@ @WAYLAND_LIBS@ @WAYLAND_EGL_LIBS@ -lm
+enlightenment_LDADD = @e_libs@ @dlopen_libs@ @cf_libs@ @VALGRIND_LIBS@
@WAYLAND_LIBS@ @WAYLAND_EGL_LIBS@ -lm
enlightenment_imc_SOURCES = \
e.h \
diff --git a/src/bin/e_main.c b/src/bin/e_main.c
index f1aa38b..5d739b1 100644
--- a/src/bin/e_main.c
+++ b/src/bin/e_main.c
@@ -1,7 +1,6 @@
#include "e.h"
-#ifdef HAVE_ECORE_IMF
-# include
-#endif
+#include
+#include
#define MAX_LEVEL 80
@@ -18,14 +17,6 @@ static double t0, t1, t2;
# define TS(x)
#endif
-#ifdef HAVE_ELEMENTARY
-#include
-#endif
-
-#ifdef HAVE_EMOTION
-#incl
[EGIT] [core/elementary] master 02/02: elm theme - add some api's to expose info so e can use elm's theme stuff
raster pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=37fe9cc77144fe42e054a082ed58a4c52a961d35
commit 37fe9cc77144fe42e054a082ed58a4c52a961d35
Author: Carsten Haitzler (Rasterman)
Date: Thu Oct 31 23:22:18 2013 +0900
elm theme - add some api's to expose info so e can use elm's theme stuff
---
src/lib/elm_theme.c | 119
src/lib/elm_theme.h | 75 +
2 files changed, 194 insertions(+)
diff --git a/src/lib/elm_theme.c b/src/lib/elm_theme.c
index 02fd673..65f09d1 100644
--- a/src/lib/elm_theme.c
+++ b/src/lib/elm_theme.c
@@ -767,3 +767,122 @@ elm_theme_data_get(Elm_Theme *th, const char *key)
if (!th) th = &(theme_default);
return _elm_theme_data_find(th, key);
}
+
+EAPI const char *
+elm_theme_group_path_find(Elm_Theme *th, const char *group)
+{
+ EINA_SAFETY_ON_NULL_RETURN_VAL(group, NULL);
+ if (!th) th = &(theme_default);
+ return _elm_theme_group_file_find(th, group);
+}
+
+static Eina_List *
+_file_find_append(Eina_List *list, const char *home, const char *f)
+{
+ char buf[PATH_MAX];
+
+ if ((f[0] == '/') || ((f[0] == '.') && (f[1] == '/')) ||
+ ((f[0] == '.') && (f[1] == '.') && (f[2] == '/')) ||
+ ((isalpha(f[0])) && (f[1] == ':')))
+ {
+list = eina_list_append(list, eina_stringshare_add(f));
+ }
+ else if (((f[0] == '~') && (f[1] == '/')))
+ {
+snprintf(buf, sizeof(buf), "%s/%s", home, f + 2);
+list = eina_list_append(list, eina_stringshare_add(buf));
+ }
+ else
+ {
+snprintf(buf, sizeof(buf), "%s/"ELEMENTARY_BASE_DIR"/themes/%s.edj",
home, f);
+list = eina_list_append(list, eina_stringshare_add(buf));
+snprintf(buf, sizeof(buf), "%s/themes/%s.edj", _elm_data_dir, f);
+list = eina_list_append(list, eina_stringshare_add(buf));
+ }
+ return list;
+}
+
+EAPI Eina_List *
+elm_theme_group_base_list(Elm_Theme *th, const char *base)
+{
+ Eina_List *list = NULL, *files = NULL, *coll, *l;
+ int len;
+ Eina_Stringshare *c, *c2, *f;
+ static const char *home = NULL;
+ EINA_SAFETY_ON_NULL_RETURN_VAL(base, NULL);
+ if (!th) th = &(theme_default);
+
+ // XXX: look results up in a hash for speed
+ len = strlen(base);
+ if (!home) // get homedir once only
+ {
+home = getenv("HOME");
+if (!home) home = "";
+ }
+ // go through overlay, themes and extensions in that order and build list
+ EINA_LIST_FOREACH(th->overlay, l, f)
+ files = _file_find_append(files, home, f);
+ EINA_LIST_FOREACH(th->themes, l, f)
+ files = _file_find_append(files, home, f);
+ EINA_LIST_FOREACH(th->extension, l, f)
+ files = _file_find_append(files, home, f);
+ // go through all possible theme files and find collections that match
+ EINA_LIST_FREE(files, f)
+ {
+coll = edje_file_collection_list(f);
+EINA_LIST_FREE(coll, c)
+ {
+ if (!strncmp(c, base, len)) // if base == start of collection str
+ {
+ EINA_LIST_FOREACH(list, l, c2) // check if already in list
+{
+ if (!strcmp(c, c2)) break;
+}
+ if (!l) // if not already in list append shared str to list
+{
+ c2 = eina_stringshare_add(c);
+ list = eina_list_append(list, c2);
+}
+ }
+ eina_stringshare_del(c);
+ }
+ }
+ // sort the list nicely at the end
+ list = eina_list_sort(list, 0, EINA_COMPARE_CB(strcmp));
+ // XXX: store results in hash for fast lookup...
+ return list;
+}
+
+EAPI const char *
+elm_theme_system_dir_get(void)
+{
+ static char *path = NULL;
+ char buf[PATH_MAX];
+
+ if (path) return path;
+ if (!path)
+ {
+snprintf(buf, sizeof(buf), "%s/themes", _elm_data_dir);
+path = strdup(buf);
+ }
+ return path;
+}
+
+EAPI const char *
+elm_theme_user_dir_get(void)
+{
+ static char *path = NULL;
+ char buf[PATH_MAX];
+
+ if (path) return path;
+ if (!path)
+ {
+char *home = getenv("HOME");
+if (!home) home = "";
+
+snprintf(buf, sizeof(buf), "%s/"ELEMENTARY_BASE_DIR"/themes", home);
+path = strdup(buf);
+ }
+ return path;
+}
+
diff --git a/src/lib/elm_theme.h b/src/lib/elm_theme.h
index 10c5f6a..268dd6f 100644
--- a/src/lib/elm_theme.h
+++ b/src/lib/elm_theme.h
@@ -432,5 +432,80 @@ EAPI Elm_Theme *elm_object_theme_get(const
Evas_Object *obj);
EAPI const char *elm_theme_data_get(Elm_Theme *th, const char *key);
/**
+ * Get the file path for an edje file for the group and theme given
+ *
+ * @param th The theme, or NULL for default theme
+ * @param group The group in the edje file to look for
+ * @return The full path to the file as a string
+ *
+ * This function looks up the given
[EGIT] [core/elementary] master 01/01: access: fixed a typo. _elm_access_object_hilight -> _elm_access_object_highlight.
seoz pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=3d45e4171c22a473999d5209c04a36063d220e5b
commit 3d45e4171c22a473999d5209c04a36063d220e5b
Author: Daniel Juyung Seo
Date: Thu Oct 31 23:01:56 2013 +0900
access: fixed a typo. _elm_access_object_hilight ->
_elm_access_object_highlight.
---
src/lib/elm_access.c | 12 ++--
src/lib/elm_widget.h | 4 ++--
src/lib/elm_win.c| 4 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/lib/elm_access.c b/src/lib/elm_access.c
index b3cf2a7..5c215d5 100644
--- a/src/lib/elm_access.c
+++ b/src/lib/elm_access.c
@@ -247,7 +247,7 @@ _access_highlight_read(Elm_Access_Info *ac, Evas_Object
*obj)
if (_elm_config->access_mode != ELM_ACCESS_MODE_OFF)
{
if (ac->on_highlight) ac->on_highlight(ac->on_highlight_data);
-_elm_access_object_hilight(obj);
+_elm_access_object_highlight(obj);
for (type = ELM_ACCESS_INFO_FIRST + 1; type < ELM_ACCESS_INFO_LAST;
type++)
{
@@ -352,13 +352,13 @@ _access_2nd_click_timeout_cb(void *data)
static void
_access_obj_hilight_del_cb(void *data __UNUSED__, Evas *e, Evas_Object *obj
__UNUSED__, void *event_info __UNUSED__)
{
- _elm_access_object_hilight_disable(e);
+ _elm_access_object_highlight_disable(e);
}
static void
_access_obj_hilight_hide_cb(void *data __UNUSED__, Evas *e, Evas_Object *obj
__UNUSED__, void *event_info __UNUSED__)
{
- _elm_access_object_hilight_disable(e);
+ _elm_access_object_highlight_disable(e);
}
static void
@@ -773,7 +773,7 @@ _elm_access_object_get(const Evas_Object *obj)
}
EAPI void
-_elm_access_object_hilight(Evas_Object *obj)
+_elm_access_object_highlight(Evas_Object *obj)
{
Evas_Object *o;
Evas_Coord x, y, w, h;
@@ -975,7 +975,7 @@ _elm_access_edje_object_part_object_unregister(Evas_Object*
obj __UNUSED__,
}
EAPI void
-_elm_access_object_hilight_disable(Evas *e)
+_elm_access_object_highlight_disable(Evas *e)
{
Evas_Object *o, *ptarget;
@@ -1304,7 +1304,7 @@ elm_access_action(Evas_Object *obj, const
Elm_Access_Action_Type type, Elm_Acces
case ELM_ACCESS_ACTION_UNHIGHLIGHT:
evas = evas_object_evas_get(obj);
if (!evas) return EINA_FALSE;
-_elm_access_object_hilight_disable(evas);
+_elm_access_object_highlight_disable(evas);
break;
case ELM_ACCESS_ACTION_HIGHLIGHT_NEXT:
diff --git a/src/lib/elm_widget.h b/src/lib/elm_widget.h
index f426d5a..82bea50 100644
--- a/src/lib/elm_widget.h
+++ b/src/lib/elm_widget.h
@@ -515,9 +515,9 @@ EAPI char*_elm_access_text_get(const
Elm_Access_Info *ac, int type,
EAPI void _elm_access_read(Elm_Access_Info *ac, int type, const
Evas_Object *obj);
EAPI void _elm_access_say(const char *txt);
EAPI Elm_Access_Info *_elm_access_info_get(const Evas_Object *obj);
-EAPI void _elm_access_object_hilight(Evas_Object *obj);
+EAPI void _elm_access_object_highlight(Evas_Object *obj);
EAPI void _elm_access_object_unhilight(Evas_Object *obj);
-EAPI void _elm_access_object_hilight_disable(Evas *e);
+EAPI void _elm_access_object_highlight_disable(Evas *e);
EAPI void _elm_access_object_register(Evas_Object *obj,
Evas_Object *hoverobj);
EAPI void _elm_access_object_unregister(Evas_Object *obj,
Evas_Object *hoverobj);
EAPI Eina_Bool_elm_access_2nd_click_timeout(Evas_Object *obj);
diff --git a/src/lib/elm_win.c b/src/lib/elm_win.c
index 19f9cbc..95f4812 100644
--- a/src/lib/elm_win.c
+++ b/src/lib/elm_win.c
@@ -875,7 +875,7 @@ _elm_win_focus_out(Ecore_Evas *ee)
}
/* access */
- _elm_access_object_hilight_disable(evas_object_evas_get(obj));
+ _elm_access_object_highlight_disable(evas_object_evas_get(obj));
/* do nothing */
/* if (sd->img_obj) */
@@ -1950,7 +1950,7 @@ _elm_win_access(Eina_Bool is_access)
if (!is_access)
{
evas = evas_object_evas_get(obj);
-if (evas) _elm_access_object_hilight_disable(evas);
+if (evas) _elm_access_object_highlight_disable(evas);
}
}
}
--
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 10:03 PM, Rafael Antognolli
wrote:
> On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler
> wrote:
>> On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL said:
>>> On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
>>> wrote:
>>> > On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
>>> > wrote:
>>> >> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
>>> >> wrote:
>>> >>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
>>> >>>
>>> >>> wrote:
>>> Hey everyone,
>>>
>>> Our current API for setting a window as fullscreen does not support
>>> specifying which output/display/monitor should be used as fullscreen.
>>> However, wayland does support it.
>>>
>>> Would it make sense to have such parameter in the fullscreen_set API?
>>> Or should it be a wayland-only API?
>>> >>>
>>> >>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
>>> >>> NULL = unset */
>>> >>>
>>> >>> the current version remains and sets on current display. Alternatively
>>> >>> we could just move the window to another display before making that
>>> >>> fullscreen, no idea if this is okay.
>>> >>
>>> >> Yeah, current version sets on current display (the one where the
>>> >> non-fullscreen window is already displayed), unless it's the first
>>> >> time that the window is going to be displayed. Otherwise it will use
>>> >> the first output. But that's up to the compositor to choose so far,
>>> >> unless we explicitly specify which output to use.
>>> >>
>>> For the latter case, how would we do that? Maybe exposing an API that
>>> allows to set the "preferred" output, and then when fullscreen_set is
>>> called, it just uses that one?
>>> >>>
>>> >>> I'd say we need to make this in one go, unless we want some kind of
>>> >>> general assignment to one display (not just for FS mode).
>>> >>
>>> >> OK...
>>> >>
>>> >>>
>>> There's also a need to specify how the output should be referred to.
>>> Using an (unsigned) int, where 0 is the first output, 1 is the second,
>>> etc? Or maybe allowing to specify something like "always the biggest
>>> one in area", or the widest one, or whatever... any thoughts?
>>> >>>
>>> >>> We'd need a way to enumerate the displays (or whatever we call them,
>>> >>> like zone, etc), they should return their properties such as size,
>>> >>> position (?), capabilities (3d/stereo? color? what do we have here?)
>>> >>> and some string to make it easy to debug.
>>> >>>
>>> >>> we have the handle to it, so it can be windowsystem agnostic
>>> >>> (Display_ID *, which can be implemented differently for windows, x11,
>>> >>> wayland...)
>>> >>
>>> >> So you are proposing that we change a good portion of our API to be
>>> >> aware of multiple displays?
>>> >>
>>> >>>
>>> That reminds me that we still have another problem. APIs such
>>> ecore_wl_screen_size_get() return only the screen size of the first
>>> monitor, not both.
>>> >>>
>>> >>> same as above, this should be based on current window (if there is a
>>> >>> window handle) or the first one (if there is not, alterntively we can
>>> >>> state it will refer to screen the mouse is over, but I guess this is
>>> >>> incorrect and makes everything less predictable).
>>> >>
>>> >> Well, that API has no argument, so it just assumes the current output.
>>> >> For a given window, one could use ecore_evas_screen_geometry_get, and
>>> >> that indeed will be attached to a given display, but only after the
>>> >> Ecore_Evas has been shown first (at least on Wayland, if I'm not
>>> >> wrong).
>>> >>
>>> What about a common API to select which output we are talking about,
>>> that must be called before any call that would refer to a specific
>>> output? The problem with this is that it would make code very
>>> wayland-specific :-/
>>> >>>
>>> >>> how so? just use the opaque handlers and abstract stuff in there.
>>> >>
>>> >> OK, so you suggestion is something like:
>>> >>
>>> >> Display {
>>> >> ID;
>>> >> size;
>>> >> position; // might be some info from xrandr, like right-of another
>>> >> display, etc, if that is even possible
>>> >> capabilities (3d/stereo? color?)
>>> >> dpi (I'm not even sure if we can query different DPIs for different
>>> >> monitors, but I've seen discussion about future work on this on
>>> >> Wayland);
>>> >> }
>>> >>
>>> >> And then change/add some APIs to refer to a specific display when
>>> >> setting things?
>>> >
>>> > change is impossible at this time (abi/api stability) and cumbersome
>>> > for most apps that don't care.
>>>
>>> Indeed.
>>>
>>> > then we must add new apis for those apps that care (ie: a presentation
>>> > tool might offer a way to choose in which display to have a fullscreen
>>> > view of slides while the notes/timer may be fullscreen on another).
>>>
>>> Why not just a ecore_evas_screen_set/get/list() set of functions that
>>> will affect the screen attached to a w
Re: [E-devel] Monitor/output parameter for fullscreen
On Thu, Oct 31, 2013 at 12:40 AM, Carsten Haitzler wrote:
> On Thu, 31 Oct 2013 10:18:31 +0900 Cedric BAIL said:
>
>> On Thu, Oct 31, 2013 at 9:24 AM, Gustavo Sverzut Barbieri
>> wrote:
>> > On Wed, Oct 30, 2013 at 6:39 PM, Rafael Antognolli
>> > wrote:
>> >> On Tue, Oct 29, 2013 at 8:17 PM, Gustavo Sverzut Barbieri
>> >> wrote:
>> >>> On Tue, Oct 29, 2013 at 7:26 PM, Rafael Antognolli
>> >>> wrote:
>> Hey everyone,
>>
>> Our current API for setting a window as fullscreen does not support
>> specifying which output/display/monitor should be used as fullscreen.
>> However, wayland does support it.
>>
>> Would it make sense to have such parameter in the fullscreen_set API?
>> Or should it be a wayland-only API?
>> >>>
>> >>> I'd say a new function fullscreen_at_display_set(Display_ID *did) /*
>> >>> NULL = unset */
>> >>>
>> >>> the current version remains and sets on current display. Alternatively
>> >>> we could just move the window to another display before making that
>> >>> fullscreen, no idea if this is okay.
>> >>
>> >> Yeah, current version sets on current display (the one where the
>> >> non-fullscreen window is already displayed), unless it's the first
>> >> time that the window is going to be displayed. Otherwise it will use
>> >> the first output. But that's up to the compositor to choose so far,
>> >> unless we explicitly specify which output to use.
>> >>
>> For the latter case, how would we do that? Maybe exposing an API that
>> allows to set the "preferred" output, and then when fullscreen_set is
>> called, it just uses that one?
>> >>>
>> >>> I'd say we need to make this in one go, unless we want some kind of
>> >>> general assignment to one display (not just for FS mode).
>> >>
>> >> OK...
>> >>
>> >>>
>> There's also a need to specify how the output should be referred to.
>> Using an (unsigned) int, where 0 is the first output, 1 is the second,
>> etc? Or maybe allowing to specify something like "always the biggest
>> one in area", or the widest one, or whatever... any thoughts?
>> >>>
>> >>> We'd need a way to enumerate the displays (or whatever we call them,
>> >>> like zone, etc), they should return their properties such as size,
>> >>> position (?), capabilities (3d/stereo? color? what do we have here?)
>> >>> and some string to make it easy to debug.
>> >>>
>> >>> we have the handle to it, so it can be windowsystem agnostic
>> >>> (Display_ID *, which can be implemented differently for windows, x11,
>> >>> wayland...)
>> >>
>> >> So you are proposing that we change a good portion of our API to be
>> >> aware of multiple displays?
>> >>
>> >>>
>> That reminds me that we still have another problem. APIs such
>> ecore_wl_screen_size_get() return only the screen size of the first
>> monitor, not both.
>> >>>
>> >>> same as above, this should be based on current window (if there is a
>> >>> window handle) or the first one (if there is not, alterntively we can
>> >>> state it will refer to screen the mouse is over, but I guess this is
>> >>> incorrect and makes everything less predictable).
>> >>
>> >> Well, that API has no argument, so it just assumes the current output.
>> >> For a given window, one could use ecore_evas_screen_geometry_get, and
>> >> that indeed will be attached to a given display, but only after the
>> >> Ecore_Evas has been shown first (at least on Wayland, if I'm not
>> >> wrong).
>> >>
>> What about a common API to select which output we are talking about,
>> that must be called before any call that would refer to a specific
>> output? The problem with this is that it would make code very
>> wayland-specific :-/
>> >>>
>> >>> how so? just use the opaque handlers and abstract stuff in there.
>> >>
>> >> OK, so you suggestion is something like:
>> >>
>> >> Display {
>> >> ID;
>> >> size;
>> >> position; // might be some info from xrandr, like right-of another
>> >> display, etc, if that is even possible
>> >> capabilities (3d/stereo? color?)
>> >> dpi (I'm not even sure if we can query different DPIs for different
>> >> monitors, but I've seen discussion about future work on this on
>> >> Wayland);
>> >> }
>> >>
>> >> And then change/add some APIs to refer to a specific display when
>> >> setting things?
>> >
>> > change is impossible at this time (abi/api stability) and cumbersome
>> > for most apps that don't care.
>>
>> Indeed.
>>
>> > then we must add new apis for those apps that care (ie: a presentation
>> > tool might offer a way to choose in which display to have a fullscreen
>> > view of slides while the notes/timer may be fullscreen on another).
>>
>> Why not just a ecore_evas_screen_set/get/list() set of functions that
>> will affect the screen attached to a window for all coming request on
>> the pointed Ecore_Evas window ? That will limit the number of function
>> we add and will not make the API to ugly in my point of view.
>
> i thi
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
On Thu, Oct 31, 2013 at 8:33 PM, Tom Hacohen wrote: > Well, suggest a list. I don't think we can easily automate that (as we > don't have last-login anymore). Gitolite might have logs. > > Well we did this kind of clean up around 2 years ago if I remember correctly. But I don't remember how we did it. What I remember is we did a *last call* at that time to give a last chance for some devs to keep the commit access. > -- > Tom. > > On 31/10/13 09:15, ChunEon Park wrote: > > I think it's time to clean up the committers who hasn't worked recently > so far. > I totally agree with this. I thought the same :) Daniel Juyung Seo (SeoZ) > > > > > > -Regards, Hermet- > > > > -Original Message- > > From: "Luis Felipe Strano Moraes" > > To: ; > > Cc: > > Sent: 2013-10-30 (수) 02:19:04 > > Subject: [EGIT] [admin/devs] master 01/01: dev-- > > > > lfelipe pushed a commit to branch master. > > > > > http://git.enlightenment.org/admin/devs.git/commit/?id=0c76c52eb1d45b5391c78e3eb1245f4321620556 > > > > commit 0c76c52eb1d45b5391c78e3eb1245f4321620556 > > Author: Luis Felipe Strano Moraes @gmail.com> > > Date: Tue Oct 29 15:17:10 2013 -0200 > > > > dev-- > > > > haven't been working on anything e-related recently > > --- > > lfelipe/id_rsa.pub 1 - > > lfelipe/info.txt9 - > > 2 files changed, 10 deletions(-) > > > > diff --git a/lfelipe/id_rsa.pub b/lfelipe/id_rsa.pub > > deleted file mode 100644 > > index 0b6ee4d..000 > > --- a/lfelipe/id_rsa.pub > > +++ /dev/null > > @@ -1 +0,0 @@ > > -ssh-rsa > B3NzaC1yc2EBIwAAAQEA1QDVDA+CkAJLbwS5OLi2Ts/DCbIpc0buzttvavnzRPs9mTb7Cf/fQg6uSoiXDKi0+acRUZ6HMZW01/ACkLzrrcIvQnP/wqhvZICSTK5NR1cL562Z938M9IYkeJzkLWN5Ftk/hnuTu+c6OGVGfeT2lpz/34qPcgvewvXZ/dSgXP5IzRr/AfF5uOmsn5r30L6/t0HTWvK13wXbd17cl/Ls1/5DhzSBhqce7UHqfCdDSAOz/N/kQua/EMnFTelnKrcK3X8RTgA99DHJLDzQt8qneUkCz+OJgmavvHdtBxf5DOZl2VCSoXkAvyRyHGIozaii9rRr7u0HWZ2V5NKFAGqmuw== > lfelipe@annie > > diff --git a/lfelipe/info.txt b/lfelipe/info.txt > > deleted file mode 100644 > > index 3fc8d81..000 > > --- a/lfelipe/info.txt > > +++ /dev/null > > @@ -1,9 +0,0 @@ > > -Login:lfelipe > > -IRC Nick: lfelipe > > -Cloak:developer/lfelipe > > -Name: Luis Felipe Strano Moraes > > -Location: Campinas, Brazil > > -E-Mail: -lfel...@profusion.mobi > > -Contributing: Evas, Ecore, Edje, Epsilon, Efreet > > -Group:Libraries > > -Platform: Ubuntu (Linux) > > > > > > > -- > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] Is there *real* documentation for edje?
Em Qui, 2013-10-31 às 08:51 +0900, Carsten Haitzler escreveu: > i know. i spent some of my early life on unix/linux paying large sums > for > o'reilly books. and reading them cover to cover. they had diagrams. i > frankly > far prefer raw simple code over those books. the code is digestible in > a > fraction of the time. :) if i have an actual working bit of code i can > compile > it, run it and then modify it to see how it wobbles when poked. poke a > bit more > and see some more wobbling. these wobbles tell me the story of how > CHANGES to > the example affect the behaviour. start small with small changes and > see. :) a > book doesn't give me that. english words don't give me that. code > does. :) but > that is my style - i know that within all fields of education > including foreign > languages, math, science, etc. etc. i always gravitated to "learn by > example". > i naturally break up the examples into their constituent parts and > know how to > manipulate them - the pattern builds over time naturally. Code is interactive. School and all non-interactive shit is difficult and pain to learn (at least for me and for you). But... I wonder how you avoid undefined behaviour code that can break in the next release of the lib/compiler or in the second compiler/platform. -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker signature.asc Description: This is a digitally signed message part -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 03/03: Implement ability to call the ecore_evas state_change function if needed.
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=1a5bdb408833a70d618ee3857eb0176a896ecfaa
commit 1a5bdb408833a70d618ee3857eb0176a896ecfaa
Author: Chris Michael
Date: Thu Oct 31 11:47:53 2013 +
Implement ability to call the ecore_evas state_change function if
needed.
NB: Currently, this will only work for fullscreen or maximized states
as other ones like sticky, withdrawn, iconic, etc, etc are not
supported via wayland protocol yet.
Signed-off-by: Chris Michael
---
.../ecore_evas/engines/wayland/ecore_evas_wayland_common.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
index fd2f52e..a40717e 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
@@ -201,8 +201,7 @@ _ecore_evas_wl_common_cb_window_configure(void *data
EINA_UNUSED, int type EINA_
if ((prev_max != ee->prop.maximized) ||
(prev_full != ee->prop.fullscreen))
{
-if (ee->func.fn_state_change)
- ee->func.fn_state_change(ee);
+_ecore_evas_wl_common_state_update(ee);
if (prev_full != ee->prop.fullscreen)
_ecore_evas_wl_common_border_update(ee);
@@ -664,6 +663,12 @@ _ecore_evas_wl_common_move(Ecore_Evas *ee, int x, int y)
}
}
+void
+_ecore_evas_wl_common_state_update(Ecore_Evas *ee)
+{
+ if (ee->func.fn_state_change) ee->func.fn_state_change(ee);
+}
+
/* Frame border:
*
* |--|
@@ -1063,6 +1068,7 @@ _ecore_evas_wl_common_layer_set(Ecore_Evas *ee, int layer)
if (layer < 1) layer = 1;
else if (layer > 255) layer = 255;
ee->prop.layer = layer;
+ _ecore_evas_wl_common_state_update(ee);
}
void
@@ -,6 +1117,7 @@ _ecore_evas_wl_common_borderless_set(Ecore_Evas *ee, int
borderless)
ee->prop.borderless = borderless;
_ecore_evas_wl_common_border_update(ee);
+ _ecore_evas_wl_common_state_update(ee);
}
void
@@ -1124,6 +1131,7 @@ _ecore_evas_wl_common_maximized_set(Ecore_Evas *ee, int
max)
wdata = ee->engine.data;
if (ee->prop.maximized == max) return;
ecore_wl_window_maximized_set(wdata->win, max);
+ _ecore_evas_wl_common_state_update(ee);
}
void
@@ -1137,6 +1145,7 @@ _ecore_evas_wl_common_fullscreen_set(Ecore_Evas *ee, int
full)
if (ee->prop.fullscreen == full) return;
wdata = ee->engine.data;
ecore_wl_window_fullscreen_set(wdata->win, full);
+ _ecore_evas_wl_common_state_update(ee);
}
void
--
[EGIT] [core/efl] master 01/03: Call _ecore_evas_mouse_move_process function on mouse_in and mouse_out events.
devilhorns pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=927358915a76b65b6810d7df87016966006d6d99
commit 927358915a76b65b6810d7df87016966006d6d99
Author: Chris Michael
Date: Thu Oct 31 09:19:38 2013 +
Call _ecore_evas_mouse_move_process function on mouse_in and mouse_out
events.
Signed-off-by: Chris Michael
---
src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
index 5373c62..fd2f52e 100644
--- a/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
+++ b/src/modules/ecore_evas/engines/wayland/ecore_evas_wayland_common.c
@@ -106,6 +106,7 @@ _ecore_evas_wl_common_cb_mouse_in(void *data EINA_UNUSED,
int type EINA_UNUSED,
if (ee->func.fn_mouse_in) ee->func.fn_mouse_in(ee);
ecore_event_evas_modifier_lock_update(ee->evas, ev->modifiers);
evas_event_feed_mouse_in(ee->evas, ev->timestamp, NULL);
+ _ecore_evas_mouse_move_process(ee, ev->x, ev->y, ev->timestamp);
ee->in = EINA_TRUE;
return ECORE_CALLBACK_PASS_ON;
}
@@ -126,6 +127,7 @@ _ecore_evas_wl_common_cb_mouse_out(void *data EINA_UNUSED,
int type EINA_UNUSED,
if (ee->in)
{
ecore_event_evas_modifier_lock_update(ee->evas, ev->modifiers);
+_ecore_evas_mouse_move_process(ee, ev->x, ev->y, ev->timestamp);
evas_event_feed_mouse_out(ee->evas, ev->timestamp, NULL);
if (ee->func.fn_mouse_out) ee->func.fn_mouse_out(ee);
if (ee->prop.cursor.object) evas_object_hide(ee->prop.cursor.object);
--
[EGIT] [core/efl] master 02/03: whitespace--
devilhorns pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=fd0c3f10f6657fac27c2641435180b0bcd3bece7 commit fd0c3f10f6657fac27c2641435180b0bcd3bece7 Author: Chris Michael Date: Thu Oct 31 09:38:34 2013 + whitespace-- Signed-off-by: Chris Michael --- src/modules/ecore_evas/engines/x/ecore_evas_x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/modules/ecore_evas/engines/x/ecore_evas_x.c b/src/modules/ecore_evas/engines/x/ecore_evas_x.c index 20ed6e2..f1e4c3f 100644 --- a/src/modules/ecore_evas/engines/x/ecore_evas_x.c +++ b/src/modules/ecore_evas/engines/x/ecore_evas_x.c @@ -1043,7 +1043,7 @@ _fake_out(void *data) Ecore_Evas *ee = data; Ecore_Evas_Engine_Data_X11 *edata = ee->engine.data; Ecore_X_Event_Mouse_Out *e = &(edata->out_ev); - + edata->outdelay = NULL; ecore_event_evas_modifier_lock_update(ee->evas, e->modifiers); --
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
Well, suggest a list. I don't think we can easily automate that (as we don't have last-login anymore). Gitolite might have logs. -- Tom. On 31/10/13 09:15, ChunEon Park wrote: > I think it's time to clean up the committers who hasn't worked recently so > far. > > > -Regards, Hermet- > > -Original Message- > From: "Luis Felipe Strano Moraes" > To: ; > Cc: > Sent: 2013-10-30 (수) 02:19:04 > Subject: [EGIT] [admin/devs] master 01/01: dev-- > > lfelipe pushed a commit to branch master. > > http://git.enlightenment.org/admin/devs.git/commit/?id=0c76c52eb1d45b5391c78e3eb1245f4321620556 > > commit 0c76c52eb1d45b5391c78e3eb1245f4321620556 > Author: Luis Felipe Strano Moraes @gmail.com> > Date: Tue Oct 29 15:17:10 2013 -0200 > > dev-- > > haven't been working on anything e-related recently > --- > lfelipe/id_rsa.pub 1 - > lfelipe/info.txt9 - > 2 files changed, 10 deletions(-) > > diff --git a/lfelipe/id_rsa.pub b/lfelipe/id_rsa.pub > deleted file mode 100644 > index 0b6ee4d..000 > --- a/lfelipe/id_rsa.pub > +++ /dev/null > @@ -1 +0,0 @@ > -ssh-rsa > B3NzaC1yc2EBIwAAAQEA1QDVDA+CkAJLbwS5OLi2Ts/DCbIpc0buzttvavnzRPs9mTb7Cf/fQg6uSoiXDKi0+acRUZ6HMZW01/ACkLzrrcIvQnP/wqhvZICSTK5NR1cL562Z938M9IYkeJzkLWN5Ftk/hnuTu+c6OGVGfeT2lpz/34qPcgvewvXZ/dSgXP5IzRr/AfF5uOmsn5r30L6/t0HTWvK13wXbd17cl/Ls1/5DhzSBhqce7UHqfCdDSAOz/N/kQua/EMnFTelnKrcK3X8RTgA99DHJLDzQt8qneUkCz+OJgmavvHdtBxf5DOZl2VCSoXkAvyRyHGIozaii9rRr7u0HWZ2V5NKFAGqmuw== > lfelipe@annie > diff --git a/lfelipe/info.txt b/lfelipe/info.txt > deleted file mode 100644 > index 3fc8d81..000 > --- a/lfelipe/info.txt > +++ /dev/null > @@ -1,9 +0,0 @@ > -Login:lfelipe > -IRC Nick: lfelipe > -Cloak:developer/lfelipe > -Name: Luis Felipe Strano Moraes > -Location: Campinas, Brazil > -E-Mail: -lfel...@profusion.mobi > -Contributing: Evas, Ecore, Edje, Epsilon, Efreet > -Group:Libraries > -Platform: Ubuntu (Linux) > -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [apps/terminology] master 01/01: terminology: add support for some more file extension.
cedric pushed a commit to branch master. http://git.enlightenment.org/apps/terminology.git/commit/?id=7b3b25634e0fee3a55515ddb92e05ad3b89ad3dc commit 7b3b25634e0fee3a55515ddb92e05ad3b89ad3dc Author: Cedric Bail Date: Thu Oct 31 18:11:35 2013 +0900 terminology: add support for some more file extension. The way to detect image is not that great in fact. Wondering if we could improve it. Those new type are quite slow btw. --- src/bin/extns.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bin/extns.h b/src/bin/extns.h index cd9e780..04f62bb 100644 --- a/src/bin/extns.h +++ b/src/bin/extns.h @@ -4,7 +4,7 @@ static const char *extn_img[] = ".bmp", ".ico", ".ppm", ".pgm", ".pbm", ".pnm", ".xpm", ".psd", ".wbmp", ".cur", ".xcf", ".xcf.gz", ".arw", ".cr2", ".crw", ".dcr", ".dng", ".k25", ".kdc", ".erf", ".mrw", ".nef", ".nrf", ".nrw", ".orf", ".raw", ".rw2", - ".pef", ".raf", ".sr2", ".srf", ".x3f", ".webp", + ".pef", ".raf", ".sr2", ".srf", ".x3f", ".webp", ".ppt", ".pptx", ".odp", NULL }; --
[EGIT] [core/evas_generic_loaders] master 01/02: pdf: add support for generic script generating pdf from anything.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/evas_generic_loaders.git/commit/?id=1b1f5f25833f14b46ef3c57a1812b43d59117f11
commit 1b1f5f25833f14b46ef3c57a1812b43d59117f11
Author: Cedric Bail
Date: Thu Oct 31 18:29:28 2013 +0900
pdf: add support for generic script generating pdf from anything.
---
src/bin/pdf/main.cpp | 70 ++--
1 file changed, 68 insertions(+), 2 deletions(-)
diff --git a/src/bin/pdf/main.cpp b/src/bin/pdf/main.cpp
index cc4f532..a68b21f 100644
--- a/src/bin/pdf/main.cpp
+++ b/src/bin/pdf/main.cpp
@@ -4,6 +4,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
@@ -199,6 +202,10 @@ void poppler_load_image(int size_w, int size_h)
int
main(int argc, char **argv)
{
+ Eina_Tmpstr *tmpdir = NULL;
+ Eina_Tmpstr *generated = NULL;
+ char *extension;
+ char *dir;
char *file;
int i;
int size_w = 0, size_h = 0;
@@ -239,12 +246,62 @@ main(int argc, char **argv)
}
}
- D("poppler_file_init\n");
D("dpi: %f\n", dpi);
D("page...: %d\n", page);
+ // This is a funny hack to call an external tool to generate a pdf that
will then be processed by poppler
+ extension = strrchr(file, '.');
+ dir = dirname(argv[0]);
+ if (extension && dir && strcmp(extension, ".pdf"))
+ {
+if (eina_file_mkdtemp("evas_generic_pdf_loaderXX", &tmpdir))
+ {
+ Eina_Strbuf *tmp;
+ FILE *cmd;
+
+ tmp = eina_strbuf_new();
+ eina_strbuf_append_printf(tmp, "%s/evas_generic_pdf_loader.%s
'%s' %s", dir, extension + 1, file, tmpdir);
+
+ cmd = popen(eina_strbuf_string_get(tmp), "r");
+ D("running preprocessing process '%s'...\n",
eina_strbuf_string_get(tmp));
+ eina_strbuf_reset(tmp);
+
+ if (cmd)
+ {
+ struct stat st;
+ const char *filename;
+ char buf[1024];
+
+ while (fgets(buf, sizeof (buf), cmd))
+;
+ pclose(cmd);
+
+ filename = basename(file);
+ generated = eina_tmpstr_add_length(filename,
strlen(filename) - strlen(extension));
+
+ eina_strbuf_append_printf(tmp, "%s/%s.pdf", tmpdir,
generated);
+
+ eina_tmpstr_del(generated);
+ generated = NULL;
+
+ if (stat(eina_strbuf_string_get(tmp), &st) == 0)
+{
+ generated =
eina_tmpstr_add_length(eina_strbuf_string_get(tmp),
+
eina_strbuf_length_get(tmp));
+ file = (char*) generated;
+}
+ }
+
+ D("generated file: '%s'\n", generated);
+ eina_strbuf_free(tmp);
+ }
+ }
+
+ // Let's force a timeout if things go wrong
timeout_init(10);
-
+
+ // Now process the pdf (or the generated pdf)
+ D("poppler_file_init\n");
if (!poppler_init(file, page, size_w, size_h))
return -1;
D("poppler_file_init done\n");
@@ -279,5 +336,14 @@ main(int argc, char **argv)
poppler_shutdown();
+ if (tmpdir)
+ {
+if (generated) unlink(generated);
+rmdir(tmpdir);
+
+eina_tmpstr_del(tmpdir);
+eina_tmpstr_del(generated);
+ }
+
return 0;
}
--
[EGIT] [core/evas_generic_loaders] master 02/02: pdf: use the generic infrastructure to generate pdf for presentation slide.
cedric pushed a commit to branch master. http://git.enlightenment.org/core/evas_generic_loaders.git/commit/?id=45b273fccdbd39e8fa6dc585c07da40a5e317767 commit 45b273fccdbd39e8fa6dc585c07da40a5e317767 Author: Cedric Bail Date: Thu Oct 31 18:30:55 2013 +0900 pdf: use the generic infrastructure to generate pdf for presentation slide. Be aware this is quite heavy and for some reason terminology seems to trigger quite a lot of try here. The generic infrastructure could be improved and use a cache of generated pdf (right now to display one image, we will generate the pdf at least 2 times !). --- src/bin/pdf/Makefile.am | 9 + src/bin/pdf/evas_generic_pdf_loader.libreoffice | 2 ++ 2 files changed, 11 insertions(+) diff --git a/src/bin/pdf/Makefile.am b/src/bin/pdf/Makefile.am index 9269c1c..52176c4 100644 --- a/src/bin/pdf/Makefile.am +++ b/src/bin/pdf/Makefile.am @@ -12,6 +12,7 @@ AM_CPPFLAGS = \ @EINA_CFLAGS@ \ @POPPLER_CFLAGS@ +bin_SCRIPTS = evas_generic_pdf_loader.libreoffice bin_PROGRAMS = evas_image_loader.pdf bindir = $(libdir)/evas/utils @@ -22,3 +23,11 @@ $(top_srcdir)/src/bin/common/timeout.c evas_image_loader_pdf_CFLAGS = evas_image_loader_pdf_LDADD = @POPPLER_LIBS@ @EINA_LIBS@ @SHM_OPEN_LIBS@ evas_image_loader_pdf_LDFLAGS = + +install-exec-hook: + ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.ppt + ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.pptx + ln -sf evas_image_loader.pdf $(DESTDIR)$(libdir)/evas/utils/evas_image_loader.odp + ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.ppt + ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.pptx + ln -sf evas_generic_pdf_loader.libreoffice $(DESTDIR)$(libdir)/evas/utils/evas_generic_pdf_loader.odp diff --git a/src/bin/pdf/evas_generic_pdf_loader.libreoffice b/src/bin/pdf/evas_generic_pdf_loader.libreoffice new file mode 100644 index 000..1809b1d --- /dev/null +++ b/src/bin/pdf/evas_generic_pdf_loader.libreoffice @@ -0,0 +1,2 @@ +#!/bin/sh +/usr/lib/libreoffice/program/soffice.bin --headless --convert-to pdf --outdir "$2" "$1" --
Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_conform.c: Added "virtualkeypad, size, changed" smart callback.
On Thu, 31 Oct 2013 18:03:48 +0900 (KST) ChunEon Park said:
> Sorry. I don't agree on this change.
>
> This callback will be called wheneven any keypad state is changed. regardless
> of the size changed.
and this should not ever be needed because conformant should be moving/resizing
the child object to account for the keypad so.. listen for move/resize events
if u care.. but your object will be adjusted appropriately by conformat...
>
> -Regards, Hermet-
>
> -Original Message-
> From: "Daniel Juyung Seo"
> To: ;
> Cc:
> Sent: 2013-10-30 (수) 16:24:37
> Subject: [EGIT] [core/elementary] master 01/01: elm_conform.c: Added
> "virtualkeypad,size,changed" smart callback.
>
> seoz pushed a commit to branch master.
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=cbd7446f0bf413ad821ac40703d2a2ca728758ef
>
> commit cbd7446f0bf413ad821ac40703d2a2ca728758ef
> Author: Daniel Juyung Seo @gmail.com>
> Date: Wed Oct 30 16:17:57 2013 +0900
>
> elm_conform.c: Added "virtualkeypad,size,changed" smart callback.
>
> When the virtualkeypad size is changed, applications get the notice.
> Applications can do internal object calculation according to the exact
> virtualkeypad size. This is useful when the exact size is important such as
> webkit usecase.
> ---
> ChangeLog 4
> NEWS 1 +
> src/lib/elm_conform.c 7 +++
> src/lib/elm_conform.h 3 +++
> 4 files changed, 15 insertions(+)
>
> diff --git a/ChangeLog b/ChangeLog
> index fbeecc7..e99d3fd 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1727,3 +1727,7 @@
> 2013-10-30 Amitesh Singh (_ami_)
>
> * image: Add support for "clicked" callback on Return/space/KP_Enter
> key press. +
> +2013-10-30 Daniel Juyung Seo (SeoZ)
> +
> +* conform: Added "virtualkeypad,size,changed" callback on
> virtualkeypad min size change. diff --git a/NEWS b/NEWS
> index 8481107..6876073 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -101,6 +101,7 @@ Additions:
> * Add elm_fileselector_hidden_visible_set/get() to show or hide hidden
> files/directories.
> * Add signals "spinner,drag,start" and "spinner,drag,stop" to the spinner
> widget.
> * Add support for "clicked" callback on Return/space/KP_Enter key press
> for image.
> + * Add "virtualkeypad,size,changed" callback on virtualkeypad min size
> change for conformant.
> Improvements:
>
> diff --git a/src/lib/elm_conform.c b/src/lib/elm_conform.c
> index 9636ab8..cb00888 100644
> --- a/src/lib/elm_conform.c
> +++ b/src/lib/elm_conform.c
> @@ -36,12 +36,14 @@ static const char SOFTKEY_PART[] = "elm.swallow.softkey";
>
> static const char SIG_VIRTUALKEYPAD_STATE_ON[] = "virtualkeypad,state,on";
> static const char SIG_VIRTUALKEYPAD_STATE_OFF[] = "virtualkeypad,state,off";
> +static const char SIG_VIRTUALKEYPAD_SIZE_CHANGED[] =
> "virtualkeypad,size,changed"; static const char SIG_CLIPBOARD_STATE_ON[] =
> "clipboard,state,on"; static const char SIG_CLIPBOARD_STATE_OFF[] =
> "clipboard,state,off";
> static const Evas_Smart_Cb_Description _smart_callbacks[] = {
> {SIG_VIRTUALKEYPAD_STATE_ON, ""},
> {SIG_VIRTUALKEYPAD_STATE_OFF, ""},
> + {SIG_VIRTUALKEYPAD_SIZE_CHANGED, ""},
> {SIG_CLIPBOARD_STATE_ON, ""},
> {SIG_CLIPBOARD_STATE_OFF, ""},
> {NULL, NULL}
> @@ -166,6 +168,8 @@ _conformant_part_sizing_eval(Evas_Object *obj,
>
> if (part_type & ELM_CONFORMANT_VIRTUAL_KEYPAD_PART)
> {
> +Evas_Coord_Rectangle rect;
> +
> #ifdef HAVE_ELEMENTARY_X
> if ((!_conformant_part_geometry_get_from_env
> ("ILLUME_KBD", &sx, &sy, &sw, &sh)) && (xwin))
> @@ -189,6 +193,9 @@ _conformant_part_sizing_eval(Evas_Object *obj,
> DBG("[KEYPAD]: size(%d,%d, %dx%d).", sx, sy, sw, sh);
> _conformant_part_size_hints_set
>(obj, sd->virtualkeypad, sx, sy, sw, sh);
> +
> +rect.x = sx; rect.y = sy; rect.w = sw; rect.h = sh;
> +evas_object_smart_callback_call(obj, SIG_VIRTUALKEYPAD_SIZE_CHANGED,
> (void *)&rect); }
>
> if (part_type & ELM_CONFORMANT_SOFTKEY_PART)
> diff --git a/src/lib/elm_conform.h b/src/lib/elm_conform.h
> index a491b95..e1187b5 100644
> --- a/src/lib/elm_conform.h
> +++ b/src/lib/elm_conform.h
> @@ -28,6 +28,9 @@
> * (@since 1.8)
> * @li "virtualkeypad,state,off": if virtualkeypad state is switched to
> "off".
> * (@since 1.8)
> + * @li "virtualkeypad,size,changed": this is called when virtualkeypad size
> is
> + * changed. @c event_info parameter is the virtualkeypad size in
> + * Evas_Coord_Rectangle structure. (@since 1.8)
> * @li "clipboard,state,on": if clipboard state is switched to "on".
> * (@since 1.8)
> * @li "clipboard,state,off": if clipboard state is switched to "off".
>
> --
>
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love
Re: [E-devel] [EGIT] [admin/devs] master 01/01: dev--
I think it's time to clean up the committers who hasn't worked recently so far. -Regards, Hermet- -Original Message- From: "Luis Felipe Strano Moraes" To: ; Cc: Sent: 2013-10-30 (수) 02:19:04 Subject: [EGIT] [admin/devs] master 01/01: dev-- lfelipe pushed a commit to branch master. http://git.enlightenment.org/admin/devs.git/commit/?id=0c76c52eb1d45b5391c78e3eb1245f4321620556 commit 0c76c52eb1d45b5391c78e3eb1245f4321620556 Author: Luis Felipe Strano Moraes @gmail.com> Date: Tue Oct 29 15:17:10 2013 -0200 dev-- haven't been working on anything e-related recently --- lfelipe/id_rsa.pub 1 - lfelipe/info.txt9 - 2 files changed, 10 deletions(-) diff --git a/lfelipe/id_rsa.pub b/lfelipe/id_rsa.pub deleted file mode 100644 index 0b6ee4d..000 --- a/lfelipe/id_rsa.pub +++ /dev/null @@ -1 +0,0 @@ -ssh-rsa B3NzaC1yc2EBIwAAAQEA1QDVDA+CkAJLbwS5OLi2Ts/DCbIpc0buzttvavnzRPs9mTb7Cf/fQg6uSoiXDKi0+acRUZ6HMZW01/ACkLzrrcIvQnP/wqhvZICSTK5NR1cL562Z938M9IYkeJzkLWN5Ftk/hnuTu+c6OGVGfeT2lpz/34qPcgvewvXZ/dSgXP5IzRr/AfF5uOmsn5r30L6/t0HTWvK13wXbd17cl/Ls1/5DhzSBhqce7UHqfCdDSAOz/N/kQua/EMnFTelnKrcK3X8RTgA99DHJLDzQt8qneUkCz+OJgmavvHdtBxf5DOZl2VCSoXkAvyRyHGIozaii9rRr7u0HWZ2V5NKFAGqmuw== lfelipe@annie diff --git a/lfelipe/info.txt b/lfelipe/info.txt deleted file mode 100644 index 3fc8d81..000 --- a/lfelipe/info.txt +++ /dev/null @@ -1,9 +0,0 @@ -Login:lfelipe -IRC Nick: lfelipe -Cloak:developer/lfelipe -Name: Luis Felipe Strano Moraes -Location: Campinas, Brazil -E-Mail: -lfel...@profusion.mobi -Contributing: Evas, Ecore, Edje, Epsilon, Efreet -Group:Libraries -Platform: Ubuntu (Linux) -- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_conform.c: Added "virtualkeypad,size,changed" smart callback.
Sorry. I don't agree on this change.
This callback will be called wheneven any keypad state is changed. regardless
of the size changed.
-Regards, Hermet-
-Original Message-
From: "Daniel Juyung Seo"
To: ;
Cc:
Sent: 2013-10-30 (수) 16:24:37
Subject: [EGIT] [core/elementary] master 01/01: elm_conform.c: Added
"virtualkeypad,size,changed" smart callback.
seoz pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=cbd7446f0bf413ad821ac40703d2a2ca728758ef
commit cbd7446f0bf413ad821ac40703d2a2ca728758ef
Author: Daniel Juyung Seo @gmail.com>
Date: Wed Oct 30 16:17:57 2013 +0900
elm_conform.c: Added "virtualkeypad,size,changed" smart callback.
When the virtualkeypad size is changed, applications get the notice.
Applications can do internal object calculation according to the exact
virtualkeypad size.
This is useful when the exact size is important such as webkit usecase.
---
ChangeLog 4
NEWS 1 +
src/lib/elm_conform.c 7 +++
src/lib/elm_conform.h 3 +++
4 files changed, 15 insertions(+)
diff --git a/ChangeLog b/ChangeLog
index fbeecc7..e99d3fd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1727,3 +1727,7 @@
2013-10-30 Amitesh Singh (_ami_)
* image: Add support for "clicked" callback on Return/space/KP_Enter
key press.
+
+2013-10-30 Daniel Juyung Seo (SeoZ)
+
+* conform: Added "virtualkeypad,size,changed" callback on
virtualkeypad min size change.
diff --git a/NEWS b/NEWS
index 8481107..6876073 100644
--- a/NEWS
+++ b/NEWS
@@ -101,6 +101,7 @@ Additions:
* Add elm_fileselector_hidden_visible_set/get() to show or hide hidden
files/directories.
* Add signals "spinner,drag,start" and "spinner,drag,stop" to the spinner
widget.
* Add support for "clicked" callback on Return/space/KP_Enter key press for
image.
+ * Add "virtualkeypad,size,changed" callback on virtualkeypad min size
change for conformant.
Improvements:
diff --git a/src/lib/elm_conform.c b/src/lib/elm_conform.c
index 9636ab8..cb00888 100644
--- a/src/lib/elm_conform.c
+++ b/src/lib/elm_conform.c
@@ -36,12 +36,14 @@ static const char SOFTKEY_PART[] = "elm.swallow.softkey";
static const char SIG_VIRTUALKEYPAD_STATE_ON[] = "virtualkeypad,state,on";
static const char SIG_VIRTUALKEYPAD_STATE_OFF[] = "virtualkeypad,state,off";
+static const char SIG_VIRTUALKEYPAD_SIZE_CHANGED[] =
"virtualkeypad,size,changed";
static const char SIG_CLIPBOARD_STATE_ON[] = "clipboard,state,on";
static const char SIG_CLIPBOARD_STATE_OFF[] = "clipboard,state,off";
static const Evas_Smart_Cb_Description _smart_callbacks[] = {
{SIG_VIRTUALKEYPAD_STATE_ON, ""},
{SIG_VIRTUALKEYPAD_STATE_OFF, ""},
+ {SIG_VIRTUALKEYPAD_SIZE_CHANGED, ""},
{SIG_CLIPBOARD_STATE_ON, ""},
{SIG_CLIPBOARD_STATE_OFF, ""},
{NULL, NULL}
@@ -166,6 +168,8 @@ _conformant_part_sizing_eval(Evas_Object *obj,
if (part_type & ELM_CONFORMANT_VIRTUAL_KEYPAD_PART)
{
+Evas_Coord_Rectangle rect;
+
#ifdef HAVE_ELEMENTARY_X
if ((!_conformant_part_geometry_get_from_env
("ILLUME_KBD", &sx, &sy, &sw, &sh)) && (xwin))
@@ -189,6 +193,9 @@ _conformant_part_sizing_eval(Evas_Object *obj,
DBG("[KEYPAD]: size(%d,%d, %dx%d).", sx, sy, sw, sh);
_conformant_part_size_hints_set
(obj, sd->virtualkeypad, sx, sy, sw, sh);
+
+rect.x = sx; rect.y = sy; rect.w = sw; rect.h = sh;
+evas_object_smart_callback_call(obj, SIG_VIRTUALKEYPAD_SIZE_CHANGED,
(void *)&rect);
}
if (part_type & ELM_CONFORMANT_SOFTKEY_PART)
diff --git a/src/lib/elm_conform.h b/src/lib/elm_conform.h
index a491b95..e1187b5 100644
--- a/src/lib/elm_conform.h
+++ b/src/lib/elm_conform.h
@@ -28,6 +28,9 @@
* (@since 1.8)
* @li "virtualkeypad,state,off": if virtualkeypad state is switched to "off".
* (@since 1.8)
+ * @li "virtualkeypad,size,changed": this is called when virtualkeypad size is
+ * changed. @c event_info parameter is the virtualkeypad size in
+ * Evas_Coord_Rectangle structure. (@since 1.8)
* @li "clipboard,state,on": if clipboard state is switched to "on".
* (@since 1.8)
* @li "clipboard,state,off": if clipboard state is switched to "off".
--
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: configure.ac: fix --with-api err msg
jeyzu pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=489e7d565a9406ee7c7249173e8e89a9c22c2a6f
commit 489e7d565a9406ee7c7249173e8e89a9c22c2a6f
Author: Jérémy Zurcher
Date: Thu Oct 31 09:25:06 2013 +0100
configure.ac: fix --with-api err msg
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index f783c49..663fd63 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,7 +47,7 @@ case "$efl_api" in
EFL_API_LEGACY_DEF=""
EFL_API_EO_DEF="#define EFL_EO_API_SUPPORT"
;;
-*) AC_MSG_ERROR([Invalid web backend: must be eo, legacy or both]) ;;
+*) AC_MSG_ERROR([Invalid api (${efl_api}): must be eo, legacy or both]) ;;
esac
AC_SUBST(EFL_API_LEGACY_DEF)
--
[EGIT] [core/efl] master 01/01: evas/proxy - decide the proxy updation in the main render process.
hermet pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=69077d19d71983e1c9fcd47607ebc1508207cf87
commit 69077d19d71983e1c9fcd47607ebc1508207cf87
Author: ChunEon Park
Date: Thu Oct 31 17:01:41 2013 +0900
evas/proxy - decide the proxy updation in the main render process.
because the proxy updation is decided in the proxy rendering time,
it couldn't be updated at the time if the source is changed before.
---
src/lib/evas/canvas/evas_object_image.c | 68 +++--
src/lib/evas/canvas/evas_render.c | 29 +-
2 files changed, 49 insertions(+), 48 deletions(-)
diff --git a/src/lib/evas/canvas/evas_object_image.c
b/src/lib/evas/canvas/evas_object_image.c
index 4e5cd3d..af42860 100644
--- a/src/lib/evas/canvas/evas_object_image.c
+++ b/src/lib/evas/canvas/evas_object_image.c
@@ -3311,7 +3311,6 @@ _proxy_subrender(Evas *eo_e, Evas_Object *eo_source,
Evas_Object *eo_proxy, Evas
Evas_Object_Protected_Data *source;
void *ctx;
int w, h;
- Eina_Bool src_redraw = EINA_FALSE;
if (!eo_source) return;
source = eo_data_scope_get(eo_source, EVAS_OBJ_CLASS);
@@ -3341,49 +3340,42 @@ _proxy_subrender(Evas *eo_e, Evas_Object *eo_source,
Evas_Object *eo_proxy, Evas
if (!proxy_write->surface) goto end;
proxy_write->w = w;
proxy_write->h = h;
- src_redraw = EINA_TRUE;
}
-if (!src_redraw)
- src_redraw = evas_object_smart_changed_get(eo_source);
-
-if (src_redraw)
- {
- ctx = e->engine.func->context_new(e->engine.data.output);
- e->engine.func->context_color_set(e->engine.data.output, ctx, 0,
0,
- 0, 0);
- e->engine.func->context_render_op_set(e->engine.data.output, ctx,
- EVAS_RENDER_COPY);
- e->engine.func->rectangle_draw(e->engine.data.output, ctx,
-proxy_write->surface, 0, 0, w, h,
-do_async);
- e->engine.func->context_free(e->engine.data.output, ctx);
-
- ctx = e->engine.func->context_new(e->engine.data.output);
-
- Eina_Bool source_clip;
- eo_do(eo_proxy, evas_obj_image_source_clip_get(&source_clip));
-
- Evas_Proxy_Render_Data proxy_render_data = {
- .eo_proxy = eo_proxy,
- .proxy_obj = proxy_obj,
- .eo_src = eo_source,
- .source_clip = source_clip
- };
- evas_render_mapped(e, eo_source, source, ctx,
proxy_write->surface,
--source->cur->geometry.x,
--source->cur->geometry.y,
-1, 0, 0, e->output.w, e->output.h,
-&proxy_render_data
+ctx = e->engine.func->context_new(e->engine.data.output);
+e->engine.func->context_color_set(e->engine.data.output, ctx, 0, 0,
+ 0, 0);
+e->engine.func->context_render_op_set(e->engine.data.output, ctx,
+ EVAS_RENDER_COPY);
+e->engine.func->rectangle_draw(e->engine.data.output, ctx,
+ proxy_write->surface, 0, 0, w, h,
+ do_async);
+e->engine.func->context_free(e->engine.data.output, ctx);
+
+ctx = e->engine.func->context_new(e->engine.data.output);
+
+Eina_Bool source_clip;
+eo_do(eo_proxy, evas_obj_image_source_clip_get(&source_clip));
+
+Evas_Proxy_Render_Data proxy_render_data = {
+ .eo_proxy = eo_proxy,
+ .proxy_obj = proxy_obj,
+ .eo_src = eo_source,
+ .source_clip = source_clip
+};
+evas_render_mapped(e, eo_source, source, ctx, proxy_write->surface,
+ -source->cur->geometry.x,
+ -source->cur->geometry.y,
+ 1, 0, 0, e->output.w, e->output.h,
+ &proxy_render_data
#ifdef REND_DBG
-, 1
+ , 1
#endif
-, do_async);
+ , do_async);
- e->engine.func->context_free(e->engine.data.output, ctx);
- }
+e->engine.func->context_free(e->engine.data.output, ctx);
proxy_write->surface = e->engine.func->image_dirty_region
- (e->engine.data.output, proxy_write->surface, 0, 0, w, h);
+ (e->engine.data.output, proxy_write->surface, 0, 0, w, h);
/*
ctx = e->engine.func->context_new(e->engine.data.output);
if (eo_isa(source, EVAS_OBJ_SMART_CLASS))
diff --git a/src/lib/evas/canvas/evas_render.c
b/src/lib/ev
[EGIT] [core/elementary] master 01/01: elementary/elc_ctxpopup.c : Focus-direction-go should be tried after checking focus next object.
woohyun pushed a commit to branch master.
http://git.enlightenment.org/core/elementary.git/commit/?id=ab4c2efb1fa75637b716cbd14416d8b723d187e8
commit ab4c2efb1fa75637b716cbd14416d8b723d187e8
Author: WooHyun Jung
Date: Thu Oct 31 16:50:48 2013 +0900
elementary/elc_ctxpopup.c : Focus-direction-go should be tried after
checking focus next object.
---
src/lib/elc_ctxpopup.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/lib/elc_ctxpopup.c b/src/lib/elc_ctxpopup.c
index ec6debc..0f26cf4 100644
--- a/src/lib/elc_ctxpopup.c
+++ b/src/lib/elc_ctxpopup.c
@@ -148,22 +148,19 @@ _elm_ctxpopup_smart_event(Eo *obj, void *_pd, va_list
*list)
{
if (sd->box)
{
- double degree = 0.0;
-
if ((!strcmp(ev->key, "Left")) ||
(!strcmp(ev->key, "KP_Left")))
- degree = 270.0;
+ elm_widget_focus_cycle(sd->box, ELM_FOCUS_LEFT);
else if ((!strcmp(ev->key, "Right")) ||
(!strcmp(ev->key, "KP_Right")))
- degree = 90.0;
+ elm_widget_focus_cycle(sd->box, ELM_FOCUS_RIGHT);
else if ((!strcmp(ev->key, "Up")) ||
(!strcmp(ev->key, "KP_Up")))
- degree = 0.0;
+ elm_widget_focus_cycle(sd->box, ELM_FOCUS_UP);
else if ((!strcmp(ev->key, "Down")) ||
(!strcmp(ev->key, "KP_Down")))
- degree = 180.0;
+ elm_widget_focus_cycle(sd->box, ELM_FOCUS_DOWN);
- elm_widget_focus_direction_go(obj, degree);
ev->event_flags |= EVAS_EVENT_FLAG_ON_HOLD;
if (ret) *ret = EINA_TRUE;
return;
--
[EGIT] [apps/terminology] master 01/01: oops - i thought i committed this - remove commented out code from prev commit
raster pushed a commit to branch master. http://git.enlightenment.org/apps/terminology.git/commit/?id=476915c5cfa355ec4bd24c9b327b594aa2eb119e commit 476915c5cfa355ec4bd24c9b327b594aa2eb119e Author: Carsten Haitzler (Rasterman) Date: Thu Oct 31 16:10:55 2013 +0900 oops - i thought i committed this - remove commented out code from prev commit --- src/bin/termio.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/bin/termio.c b/src/bin/termio.c index 4168566..d54d496 100644 --- a/src/bin/termio.c +++ b/src/bin/termio.c @@ -4490,7 +4490,6 @@ termio_mouseover_suspend_pushpop(Evas_Object *obj, int dir) if (sd->anim) ecore_animator_del(sd->anim); sd->anim = NULL; _smart_apply(obj); -//evas_object_smart_callback_call(obj, "changed", NULL); } else _smart_update_queue(obj, sd); --
[EGIT] [apps/terminology] master 01/01: unbreak inlined media being unparented when tab selector is used
raster pushed a commit to branch master.
http://git.enlightenment.org/apps/terminology.git/commit/?id=5958eff3380552febfe4dba397ee04dae9ae31d8
commit 5958eff3380552febfe4dba397ee04dae9ae31d8
Author: Carsten Haitzler (Rasterman)
Date: Thu Oct 31 16:07:05 2013 +0900
unbreak inlined media being unparented when tab selector is used
82f4d3546a78a8f0280ac912816e86f6b2c77404 introduced this bug (oct 20
2013 - discomfitor). now missing a _smart_apply() causes the bug. why
- not sure.
---
src/bin/termio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/bin/termio.c b/src/bin/termio.c
index cc234d3..4168566 100644
--- a/src/bin/termio.c
+++ b/src/bin/termio.c
@@ -4489,6 +4489,8 @@ termio_mouseover_suspend_pushpop(Evas_Object *obj, int
dir)
{
if (sd->anim) ecore_animator_del(sd->anim);
sd->anim = NULL;
+_smart_apply(obj);
+//evas_object_smart_callback_call(obj, "changed", NULL);
}
else
_smart_update_queue(obj, sd);
--
[EGIT] [core/efl] master 01/01: evil: let's try if we only use that macro.
cedric pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=8f97de91a346af8692d9e292a5ff73b75f820992
commit 8f97de91a346af8692d9e292a5ff73b75f820992
Author: Cedric Bail
Date: Thu Oct 31 16:05:38 2013 +0900
evil: let's try if we only use that macro.
---
pc/evil.pc.in| 2 +-
src/Makefile_Evil.am | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/pc/evil.pc.in b/pc/evil.pc.in
index cf4b855..2331c27 100644
--- a/pc/evil.pc.in
+++ b/pc/evil.pc.in
@@ -10,4 +10,4 @@ Description: Library that ports on Windows some specific Unix
functions.
Version: @VERSION@
Libs: -L${libdir} -levil
Libs.private:
-Cflags: -I${includedir}/evil-@VMAJ@ @EFL_WINDOWS_VERSION_CFLAGS@
-mms-bitfields -D__MINGW_PRINTF_FORMAT
+Cflags: -I${includedir}/evil-@VMAJ@ @EFL_WINDOWS_VERSION_CFLAGS@
-mms-bitfields -D__USE_MINGW_ANSI_STDIO
diff --git a/src/Makefile_Evil.am b/src/Makefile_Evil.am
index 9e68b6e..b6b4e0a 100644
--- a/src/Makefile_Evil.am
+++ b/src/Makefile_Evil.am
@@ -58,7 +58,7 @@ else
lib_evil_libevil_la_SOURCES += lib/evil/evil_link_xp.cpp
endif
-lib_evil_libevil_la_CFLAGS = @EVIL_CFLAGS@ @EVIL_CFLAGS_WRN@
-D__MINGW_PRINTF_FORMAT
+lib_evil_libevil_la_CFLAGS = @EVIL_CFLAGS@ @EVIL_CFLAGS_WRN@
-D__USE_MINGW_ANSI_STDIO
lib_evil_libevil_la_CXXFLAGS = @EVIL_CXXFLAGS@ @EVIL_CFLAGS@
lib_evil_libevil_la_LIBADD = @EVIL_LIBS@
lib_evil_libevil_la_LDFLAGS = @EFL_LTLIBRARY_FLAGS@
--
