[EGIT] [core/efl] master 02/03: ecore_cocoa: release Ecore_Cocoa as stable
jayji pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=51f2488b78a8cf3c90ff5a2611742fc9afbb0f52
commit 51f2488b78a8cf3c90ff5a2611742fc9afbb0f52
Author: Jean Guyomarc'h
Date: Sat Jun 25 12:21:44 2016 +0200
ecore_cocoa: release Ecore_Cocoa as stable
---
src/lib/ecore_cocoa/Ecore_Cocoa.h | 75 ++-
1 file changed, 59 insertions(+), 16 deletions(-)
diff --git a/src/lib/ecore_cocoa/Ecore_Cocoa.h
b/src/lib/ecore_cocoa/Ecore_Cocoa.h
index a9d8527..a1c1e22 100644
--- a/src/lib/ecore_cocoa/Ecore_Cocoa.h
+++ b/src/lib/ecore_cocoa/Ecore_Cocoa.h
@@ -8,16 +8,6 @@
#ifndef __ECORE_COCOA_H__
#define __ECORE_COCOA_H__
-/*
- * DO NOT USE THIS HEADER. IT IS WORK IN PROGRESS. IT IS NOT FINAL AND
- * THE API MAY CHANGE.
- */
-
-#ifndef ECORE_COCOA_WIP_GNSIDNQI
-# warning "You are using a work in progress API. This API is not stable"
-# warning "and is subject to change. You use this at your own risk."
-#endif
-
#include
#ifdef EAPI
@@ -43,6 +33,7 @@ extern "C" {
/**
* @typedef Ecore_Cocoa_Window
* Opaque handler to manipulate a Cocoa Window through Ecore
+ * @since 1.18
*/
typedef struct _Ecore_Cocoa_Window Ecore_Cocoa_Window;
#endif /* ! _ECORE_COCOA_WINDOW_PREDEF */
@@ -50,36 +41,42 @@ typedef struct _Ecore_Cocoa_Window Ecore_Cocoa_Window;
/**
* @typedef Ecore_Cocoa_Screen
* Opaque handler to manipulate a Cocoa Screen through Ecore
+ * @since 1.18
*/
typedef struct _Ecore_Cocoa_Screen Ecore_Cocoa_Screen;
/**
* @typedef Ecore_Cocoa_Object
* Opaque handler to refer to an objective-c object (aka id)
+ * @since 1.18
*/
typedef void Ecore_Cocoa_Object;
/**
* @typedef Ecore_Cocoa_Event_Window_Resize_Request
* Type of event thrown when a Cocoa window is resized
+ * @since 1.18
*/
typedef struct _Ecore_Cocoa_Event_Window_Resize_Request
Ecore_Cocoa_Event_Window_Resize_Request;
/**
* @typedef Ecore_Cocoa_Event_Window_Focused
* Type of event thrown when a Cocoa window receives focus
+ * @since 1.18
*/
typedef struct _Ecore_Cocoa_Event_Window_Focused
Ecore_Cocoa_Event_Window_Focused;
/**
* @typedef Ecore_Cocoa_Event_Window_Unfocused
* Type of event thrown when a Cocoa window loses the focus
+ * @since 1.18
*/
typedef struct _Ecore_Cocoa_Event_Window_Unfocused
Ecore_Cocoa_Event_Window_Unfocused;
/**
* @typedef Ecore_Cocoa_Event_Window_Destroy
* Type of event thrown when a Cocoa window gets destoyed
+ * @since 1.18
*/
typedef struct _Ecore_Cocoa_Event_Window_Destroy
Ecore_Cocoa_Event_Window_Destroy;
@@ -87,6 +84,7 @@ typedef struct _Ecore_Cocoa_Event_Window_Destroy
Ecore_Cocoa_Event_Window_Destro
* @typedef Ecore_Cocoa_Cursor
* Values of the Cocoa cursors handled by Ecore_Cocoa
* See
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSCursor_Class/index.html
for images of each cursors.
+ * @since 1.18
*/
typedef enum
{
@@ -117,25 +115,38 @@ typedef enum
* @def ECORE_COCOA_CURSOR_DEFAULT
* Defines the default Cocoa cursor, to be used when nothing
* is specified or as a fallback.
+ * @since 1.18
*/
#define ECORE_COCOA_CURSOR_DEFAULT ECORE_COCOA_CURSOR_ARROW
-/** Event triggered when a Cocoa window receives focus */
+/**
+ * Event triggered when a Cocoa window receives focus
+ * @since 1.18
+ */
EAPI extern int ECORE_COCOA_EVENT_WINDOW_FOCUSED;
-/** Event triggered when a Cocoa window loses focus */
+/**
+ * Event triggered when a Cocoa window loses focus
+ * @since 1.18
+ */
EAPI extern int ECORE_COCOA_EVENT_WINDOW_UNFOCUSED;
-/** Event triggered when a Cocoa window is resized */
+/**
+ * Event triggered when a Cocoa window is resized
+ * @since 1.18
+ */
EAPI extern int ECORE_COCOA_EVENT_WINDOW_RESIZE_REQUEST;
-/** Event triggered when a Cocoa window get destroyed */
+/** Event triggered when a Cocoa window get destroyed
+ * @since 1.18
+ */
EAPI extern int ECORE_COCOA_EVENT_WINDOW_DESTROY;
/**
* @struct _Ecore_Cocoa_Event_Window_Resize_Request
* Data available when a window is resized
+ * @since 1.18
*/
struct _Ecore_Cocoa_Event_Window_Resize_Request
{
@@ -147,6 +158,7 @@ struct _Ecore_Cocoa_Event_Window_Resize_Request
/**
* @struct _Ecore_Cocoa_Event_Window_Focused
* Data available when a Cocoa window receives focus
+ * @since 1.18
*/
struct _Ecore_Cocoa_Event_Window_Focused
{
@@ -156,6 +168,7 @@ struct _Ecore_Cocoa_Event_Window_Focused
/**
* @struct _Ecore_Cocoa_Event_Window_Unfocused
* Data available when a Cocoa window losrs focus
+ * @since 1.18
*/
struct _Ecore_Cocoa_Event_Window_Unfocused
{
@@ -165,6 +178,7 @@ struct _Ecore_Cocoa_Event_Window_Unfocused
/**
* @struct _Ecore_Cocoa_Event_Window_Destroy
* Data available when a Cocoa window is destroyed
+ * @since 1.18
*/
struct _Ecore_Cocoa_Event_Window_Destroy
{
@@ -174,7 +188,8 @@ struct _Ecore_Cocoa_Event_Window_Destroy
/**
* @typedef Ecore_Cocoa_Cnp_Type
* Type used to interact with the Cocoa past
[EGIT] [core/efl] master 03/03: elementary: include Ecore_Cocoa.h normally
jayji pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=5899858964f3484c5a41a13425435c78ce63b35d commit 5899858964f3484c5a41a13425435c78ce63b35d Author: Jean Guyomarc'h Date: Sat Jun 25 12:24:35 2016 +0200 elementary: include Ecore_Cocoa.h normally Guards are not necessary anymore. --- src/lib/elementary/elm_priv.h | 5 - 1 file changed, 5 deletions(-) diff --git a/src/lib/elementary/elm_priv.h b/src/lib/elementary/elm_priv.h index 09f3ce9..79e33fd 100644 --- a/src/lib/elementary/elm_priv.h +++ b/src/lib/elementary/elm_priv.h @@ -13,11 +13,6 @@ #include #endif #ifdef HAVE_ELEMENTARY_COCOA -/* Ecore_Cocoa is still in Beta. In Elementary, we know what we are - * doing, so let's silent the disclaimer... */ -# ifndef ECORE_COCOA_WIP_GNSIDNQI -# define ECORE_COCOA_WIP_GNSIDNQI -#endif # include #endif #ifdef HAVE_ELEMENTARY_WIN32 --
[EGIT] [core/efl] master 01/03: ecore_cocoa: mark clipboard API as BETA
jayji pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=078882715800f34d42f21a4de8bb45fc09c0e041 commit 078882715800f34d42f21a4de8bb45fc09c0e041 Author: Jean Guyomarc'h Date: Sat Jun 25 12:13:59 2016 +0200 ecore_cocoa: mark clipboard API as BETA Also, Since the API is beta, don't make is available to Doxygen. --- src/lib/ecore_cocoa/Ecore_Cocoa.h | 49 --- 1 file changed, 30 insertions(+), 19 deletions(-) diff --git a/src/lib/ecore_cocoa/Ecore_Cocoa.h b/src/lib/ecore_cocoa/Ecore_Cocoa.h index 7f7ca6d..a9d8527 100644 --- a/src/lib/ecore_cocoa/Ecore_Cocoa.h +++ b/src/lib/ecore_cocoa/Ecore_Cocoa.h @@ -465,7 +465,34 @@ EAPI Ecore_Cocoa_Object *ecore_cocoa_window_get(const Ecore_Cocoa_Window *window EINA_ARG_NONNULL(1) EINA_WARN_UNUSED_RESULT; + +/** + * Set the Cocoa cursor for a given Cocoa window + * @param win The Cocoa window on which the cursor is to be changed. + * @param c The cursor to be set + */ +EAPI void ecore_cocoa_window_cursor_set(Ecore_Cocoa_Window *win, +Ecore_Cocoa_Cursor c) + EINA_ARG_NONNULL(1); + /** + * Hide or show the Cocoa cursor for a given Cocoa window + * @param win The Cocoa window on which the cursor is to be hid + * @param show Shows the cursor if EINA_TRUE. Hides it if EINA_FALSE + * + */ +EAPI void ecore_cocoa_window_cursor_show(Ecore_Cocoa_Window *win, Eina_Bool show); + EINA_ARG_NONNULL(1); + + + +/* + * The clipboard API is still BETA + */ + +#ifdef EFL_BETA_API_SUPPORT + +/* * Set the clipboard of Cocoa (NSPasteboard) * @param data The contents to be set in the clipboard * @param size The size in bytes of @c data @@ -476,7 +503,7 @@ EAPI Eina_Bool ecore_cocoa_clipboard_set(const void *data, int size, Ecore_Cocoa_Cnp_Type type); -/** +/* * Get the contents of the Cocoa clipboard * @param size Pointer used to retrieve the size of the received contents * @param type The type of object to retrieve from the clipboard @@ -492,28 +519,12 @@ EAPI void *ecore_cocoa_clipboard_get(int *size, Ecore_Cocoa_Cnp_Type *retrieved_types) EINA_WARN_UNUSED_RESULT; -/** +/* * Deletes the contents of the Cocoa clipboard */ EAPI void ecore_cocoa_clipboard_clear(void); -/** - * Set the Cocoa cursor for a given Cocoa window - * @param win The Cocoa window on which the cursor is to be changed. - * @param c The cursor to be set - */ -EAPI void ecore_cocoa_window_cursor_set(Ecore_Cocoa_Window *win, -Ecore_Cocoa_Cursor c) - EINA_ARG_NONNULL(1); - -/** - * Hide or show the Cocoa cursor for a given Cocoa window - * @param win The Cocoa window on which the cursor is to be hid - * @param show Shows the cursor if EINA_TRUE. Hides it if EINA_FALSE - * - */ -EAPI void ecore_cocoa_window_cursor_show(Ecore_Cocoa_Window *win, Eina_Bool show); - EINA_ARG_NONNULL(1); +#endif /* EFL_BETA_API_SUPPORT */ #ifdef __cplusplus } --
[EGIT] [core/enlightenment] master 01/01: emix: update sink of sink_input when changed
bu5hm4n pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=4f0e3bce842ef42f07b04183c633e31f95903d36
commit 4f0e3bce842ef42f07b04183c633e31f95903d36
Author: Marcel Hollerbach
Date: Sat Jun 25 17:12:35 2016 +0200
emix: update sink of sink_input when changed
this fixes none changing sinks in the app.
---
src/modules/mixer/lib/backends/pulseaudio/pulse.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/modules/mixer/lib/backends/pulseaudio/pulse.c
b/src/modules/mixer/lib/backends/pulseaudio/pulse.c
index 15fadea..40dda05 100644
--- a/src/modules/mixer/lib/backends/pulseaudio/pulse.c
+++ b/src/modules/mixer/lib/backends/pulseaudio/pulse.c
@@ -351,6 +351,7 @@ _sink_input_changed_cb(pa_context *c EINA_UNUSED,
void *userdata EINA_UNUSED)
{
Sink_Input *input = NULL, *i;
+ Sink *s = NULL;
Eina_List *l;
EINA_SAFETY_ON_NULL_RETURN(ctx);
@@ -387,6 +388,12 @@ _sink_input_changed_cb(pa_context *c EINA_UNUSED,
input->base.volume = _pa_cvolume_convert(&info->volume);
input->base.mute = !!info->mute;
+ EINA_LIST_FOREACH(ctx->sinks, l, s)
+ {
+if (s->idx == (int)info->sink)
+ input->base.sink = (Emix_Sink *)s;
+ }
+
if (ctx->cb)
ctx->cb((void *)ctx->userdata, EMIX_SINK_INPUT_CHANGED_EVENT,
(Emix_Sink_Input *)input);
--
Re: [E-devel] promises...
On Sat, Jun 25, 2016 at 11:12 AM, Carsten Haitzler wrote: > On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida > said: > >> Hello, >> >> I still don't get it why promises should be an all-or-nothing thing. It must >> be usable for all scenarios possible or we should drop it and >> live with events which are impossible to translate to the real semantics >> of asynchronous operations (I'm calling an asynchronous operation >> one that returns a value asynchronously) to bindings that already have >> a concept of asynchronous operations. > > i don't know if anyone said it should be all or nothing. i have said that > given > the newness and disagreements on promises that we need to use them very > carefully and avoid usage "all over the place" for now until we can settle > them > down. if we were all happy with them and agreed on them then things may be > different, but that is not the case. > > i think a big difference is our view of promises. to me a promise is an OBJECT > that REPRESENTS the async action (and then is responsible for calling the > correct callbacks and for storing the value until all such callbacks are > called > etc. etc.). you (and cedric) keep referring to promises as async values. at > least in every language binding they are OBJECTS. they have methods on them > (p.then(), and to cancel p.cancel() for starters). Well, the object nomenclature is a little misleading IMO. For C++ at least everything is an object, even ints. So I agree a promise is an object. But its sole purpose, IMO, is to hold a value that will be available in the future. So both are right. IMO, the only problem with Eolizing Promise is 1. paying for things we don't need; 2. The intricacies of other Eolian features, such as inheritance for example. I'm not completely against it being an Eo object however, though IMO it is not a good tradeoff. But I can live with it and would be really happy to build the JavaScript binding on top of that if I can deliver the same semantics (on steroids) that normal JavaScript promises have. The intrincacies of Eo properties, however, are not very easy to foresee IMO. So, how inheritance should work? This is not a rhetorical question, because right now we have a built-in called promise in Eolian that says that a promise is being returned, because we don't have parameterized classes in Eolian, so how should bindings know that a derived class with more events are being used? If we use the class name of the subclassed promise then we need new syntax to allow parameterizing that in Eolian. Should we? >> One example is making promises open to add new events through >> inheritance. However, let's say that it is really desirable, so we can >> all compromise on a middle term, we need to have a way to support >> that in bindings in a way that is natural in the binding languages, and >> IMO that is the _most_important_part_ and I have been repeating >> myself about this since I introduced the promise idea in january, but >> let me repeat again: > > yes, and since promises are objects in every language and binding we > support... > this isn't much of an issue. we can extend progress events as eo events since > they wont be a minimal base requirement. will these events be really common? I actually like the idea of using events for progress, because it is an event, it has all the properties of events. However, it just has one single problem, which is the race condition of progress being available and when the event is registered. This problem also existed with Eina_Promise however, and we fixed by adding strict_promise concept which would only send progress when a progress callback was registered. This could be case for Eo as well, but we need to be able to differentiate, because a strict_promise can lead to deadlock if the user never registers any progress callback. > good question. at least in our current usage progress is not used, so... why > not extend that via eo events? this would work in every language we bind to as > long as we return the promise objects from our api's (they will be of the > right > type then with these extensions). OK. > the natural bindings in c++ (libstdc++) have no progress, so when we add this > - > our promises are not 1005 natural. this is something we have to accept, OR we > will require efl to be the lowest common denominator of all languages and that > would be far worse then even just using events on objects for async work. We will accept it can be more than what the language offers. This is common-place even for STL implementations. They have extensions in numerous ways. [snip] >> Regards, >> -- >> Felipe Magno de Almeida Regards, -- Felipe Magno de Almeida -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has some
Re: [E-devel] promises...
On Sat, 25 Jun 2016 10:28:37 -0300 Felipe Magno de Almeida said: > Hello, > > I still don't get it why promises should be an all-or-nothing thing. It must > be usable for all scenarios possible or we should drop it and > live with events which are impossible to translate to the real semantics > of asynchronous operations (I'm calling an asynchronous operation > one that returns a value asynchronously) to bindings that already have > a concept of asynchronous operations. i don't know if anyone said it should be all or nothing. i have said that given the newness and disagreements on promises that we need to use them very carefully and avoid usage "all over the place" for now until we can settle them down. if we were all happy with them and agreed on them then things may be different, but that is not the case. i think a big difference is our view of promises. to me a promise is an OBJECT that REPRESENTS the async action (and then is responsible for calling the correct callbacks and for storing the value until all such callbacks are called etc. etc.). you (and cedric) keep referring to promises as async values. at least in every language binding they are OBJECTS. they have methods on them (p.then(), and to cancel p.cancel() for starters). > One example is making promises open to add new events through > inheritance. However, let's say that it is really desirable, so we can > all compromise on a middle term, we need to have a way to support > that in bindings in a way that is natural in the binding languages, and > IMO that is the _most_important_part_ and I have been repeating > myself about this since I introduced the promise idea in january, but > let me repeat again: yes, and since promises are objects in every language and binding we support... this isn't much of an issue. we can extend progress events as eo events since they wont be a minimal base requirement. will these events be really common? good question. at least in our current usage progress is not used, so... why not extend that via eo events? this would work in every language we bind to as long as we return the promise objects from our api's (they will be of the right type then with these extensions). the natural bindings in c++ (libstdc++) have no progress, so when we add this - our promises are not 1005 natural. this is something we have to accept, OR we will require efl to be the lowest common denominator of all languages and that would be far worse then even just using events on objects for async work. > Promises must be a way to have well-defined-semantics for bindings > to be able to translate that to what is natural and native in the binding > languages. The whole efl interfaces effort, afaik, is not about C API, > because we already have a stable C API! We need to think about > bindings too, because the efl interfaces effort is, afaik, about having > usable efl interface api for bindings, which we don't have yet. We > can't create bad C APIs in the process ofc, but, afaik, this is not > about creating new C APIs. actually... efl interfaces started to improve/clean our c interfaces. bindings came later. but i agree with you that things like promises need to map to bindings nicely. they ALSO have to be nice in c. if the bindings are done manually for other langs then we need to focus on making the c api nice. as long as this does not PRECLUDE manual bindings from making promises work in the language native way. that's why i don't see that e HAVE to split promises in c into owner/future. that can be done manually in the bindings *IF* the language does a split. js does not. c++ does. java does. lua has no promise so it's whatever we decide (likely the js way). but in C there is no real point in splitting between promise owner and future. > I work on most bindings for EFL, so yeah, I'll be very annoying about > it, because I don't want to create bad bindings. I don't think anybody > wants to work to do bad things, I'm not different. I want to be > proud of what I deliver. And that means writing bindings that people > will want to use, and not that people will curse me because they > _have_ to use it. Also, I think it will help EFL a lot if we get it > to be used by more languages. see above. i agree. but we cant go fucking up our c api as a result. > So, bindings already know the special relationship between derived > classes of Future (I'm using cedric's nomenclature here) and > translate new events directly. So I think this is doable. With the > lifetime thing, well, for bindings I don't care if we drop it any > automagical things because bindings will deal it correctly. So > that makes things easier. Implementing data models in C > might be a little less sexy, but still way easier than using events > and caching all things and etc. if the model objects do NOT cache data like properties... they are going to be so horrible in performance... it's not funny. any re-fetch of a property by the ui for example will need a complete re
Re: [E-devel] What is still pending for 1.18 before the freeze starts
On Sat, 25 Jun 2016 09:08:33 -0300 Felipe Magno de Almeida
said:
> On Fri, Jun 24, 2016 at 7:59 PM, Carsten Haitzler
> wrote:
> > On Fri, 24 Jun 2016 07:58:44 -0500 Stephen Houston
> > said:
> >
> >> I would like to add that the theme bugs on Genlist need fixing also. Two
> >> Phab tickets in particular. 1) There is a clipping bug where, a Genlist
> >> large enough to scroll, scrolls out of it's bounds and covers other widget.
> >> The out of bounds content is invisible of course so you don't see it, but
> >> you can still click into it. 2) Genlist tree, the row alternating colors
> >> becomes messed up if a tree items children are created upon expand.
> >
> > 1) that's not a theme bug. it's an evas clipping/ object bug of some sort.
> > 2) also not a theme bug but code bug. it just somehow doesnt re-init items
> > with the correct edje group for odd/even.
> >
> >> Both of these bugs have Phab tickets. The eio monitor has a Phab ticket as
> >> well and Cedric is addressing it for the release I believe.
> >> On Jun 23, 2016 7:35 AM, "Stefan Schmidt" wrote:
> >
> > we have deeper problems. promises.
> >
> > right now i'm tempted to just call it quits on promises. remove them. do
> > that stuff with events on objects. i'm tired of the disconnect on promises
> > so drop them entirely. my patience is running thin.
>
> Just know we will be either killing the Node.JS bindings or requiring
> manual code.
>
> People will not want to use a binding that will be written like this:
>
> download = new efl.net.url_download('http:// ... ');
> download.on('result', function () { .. });
> download.on('error', function () { ... });
> download.on('progress', function () { ... });
> download.work(); // the async operation
>
> This is horrible, people will expect that to work like this:
unless we agree on promises ... yes. they will have to go and we'll have the
above. i will not accept any implementation or solution that makes the c api
harder to use than it needs to be. first and foremost. SECOND it then has to
translate to other languages.
since you want to do promise bindings manually, then map it however you like
manually with whatever wrapping etc. but this should not cause the api and
usage in c to be harder than it needs to be.
> efl.net.url_download('http:// ...').then
> (
>function (file) // success
>{
> return x;
>},
>function (e) // error
>{
>},
>function (p) // progress
>{
>}
> ).then( function (x) { ... });
>
> This is what we have been advocating since the beginning, and we don't
> need a huge super Eolian class to have that in all bindings, we just
> need well defined semantics of asynchronous operations. We can
> work with Eolian/Eo Promise for that as well and that's all _I_ ask so I
> can sell EFL idea for other communities as well.
> However, you wanted to have a super uber promise first and now
> you just want to drop everything that even remotely allows us
> the second syntax.
eh? i want nothing of the sort. there is no reason to make promises as complex
as proposed in c.
> I have to ask, do we even care about bindings or not?
i care, but if we are going to disagree on promises in core efl for much
longer, then we just have to drop them. yes. people will have to do the "obj.on
()" stuff. it works. it's better than marching on with promises given the
extreme disagreements on them and their implementation, api and behaviour. js
didn't have promises for many many many years. we will have to march on without
them if we can't agree on them in the core of efl.
--
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: e_comp: silence warning, this time really
On Sat, Jun 25, 2016 at 10:02:47AM -0400, Michael Blumenkrantz wrote: > On Sat, 25 Jun 2016 07:01:25 -0700 > Marcel Hollerbach wrote: > > > bu5hm4n pushed a commit to branch master. > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=afeb588632e98bcac3b20258d72790c7236cf071 > > > > commit afeb588632e98bcac3b20258d72790c7236cf071 > > Author: Marcel Hollerbach > > Date: Sat Jun 25 16:00:30 2016 +0200 > > > > e_comp: silence warning, this time really > > > > as said on the ML > > --- > > src/bin/e_comp_object.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/bin/e_comp_object.c b/src/bin/e_comp_object.c > > index a6b0039..4f90b4c 100644 > > --- a/src/bin/e_comp_object.c > > +++ b/src/bin/e_comp_object.c > > @@ -1284,7 +1284,7 @@ _e_comp_intercept_resize(void *data, Evas_Object > > *obj, int w, int h) > > break; > > } > > if (cw->ec->internal_elm_win && (!cw->ec->moving) && > > (!e_client_util_resizing_get(cw->ec)) && > > - (!cw->ec->fullscreen) && ((!cw->ec->maximized) == E_MAXIMIZE_NONE) > > && > > + (!cw->ec->fullscreen) && (!cw->ec->maximized) && > > e_win_centered_get(cw->ec->internal_elm_win)) > > e_comp_object_util_center(obj); > > cw->force_move = 0; > > > > also weren't there other occurrences of it? I have not found any other. > > -- > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: e_comp: silence warning, this time really
On Sat, 25 Jun 2016 07:01:25 -0700 Marcel Hollerbach wrote: > bu5hm4n pushed a commit to branch master. > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=afeb588632e98bcac3b20258d72790c7236cf071 > > commit afeb588632e98bcac3b20258d72790c7236cf071 > Author: Marcel Hollerbach > Date: Sat Jun 25 16:00:30 2016 +0200 > > e_comp: silence warning, this time really > > as said on the ML > --- > src/bin/e_comp_object.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/bin/e_comp_object.c b/src/bin/e_comp_object.c > index a6b0039..4f90b4c 100644 > --- a/src/bin/e_comp_object.c > +++ b/src/bin/e_comp_object.c > @@ -1284,7 +1284,7 @@ _e_comp_intercept_resize(void *data, Evas_Object *obj, > int w, int h) > break; > } > if (cw->ec->internal_elm_win && (!cw->ec->moving) && > (!e_client_util_resizing_get(cw->ec)) && > - (!cw->ec->fullscreen) && ((!cw->ec->maximized) == E_MAXIMIZE_NONE) && > + (!cw->ec->fullscreen) && (!cw->ec->maximized) && > e_win_centered_get(cw->ec->internal_elm_win)) > e_comp_object_util_center(obj); > cw->force_move = 0; > also weren't there other occurrences of it? -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: e_comp: silence warning
On Sat, Jun 25, 2016 at 09:53:40AM -0400, Michael Blumenkrantz wrote: > On Sat, 25 Jun 2016 06:37:38 -0700 > Marcel Hollerbach wrote: > > > bu5hm4n pushed a commit to branch master. > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=a80bc133369689976c810ad4178a7528a91d1136 > > > > commit a80bc133369689976c810ad4178a7528a91d1136 > > Author: Marcel Hollerbach > > Date: Sat Jun 25 15:29:45 2016 +0200 > > > > e_comp: silence warning > > > > after talking to zmike, this is by intend. > > --- > > src/bin/e_comp_object.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/bin/e_comp_object.c b/src/bin/e_comp_object.c > > index a495f07..a6b0039 100644 > > --- a/src/bin/e_comp_object.c > > +++ b/src/bin/e_comp_object.c > > @@ -1284,7 +1284,7 @@ _e_comp_intercept_resize(void *data, Evas_Object > > *obj, int w, int h) > > break; > > } > > if (cw->ec->internal_elm_win && (!cw->ec->moving) && > > (!e_client_util_resizing_get(cw->ec)) && > > - (!cw->ec->fullscreen) && (!cw->ec->maximized == E_MAXIMIZE_NONE) && > > + (!cw->ec->fullscreen) && ((!cw->ec->maximized) == E_MAXIMIZE_NONE) > > && > > I meant this line should be > > (!cw->ec->fullscreen) && (!cw->ec->maximized) && Ok, sorry, fixed now. > > > e_win_centered_get(cw->ec->internal_elm_win)) > > e_comp_object_util_center(obj); > > cw->force_move = 0; > > > > -- > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 01/01: e_comp: silence warning, this time really
bu5hm4n pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=afeb588632e98bcac3b20258d72790c7236cf071 commit afeb588632e98bcac3b20258d72790c7236cf071 Author: Marcel Hollerbach Date: Sat Jun 25 16:00:30 2016 +0200 e_comp: silence warning, this time really as said on the ML --- src/bin/e_comp_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bin/e_comp_object.c b/src/bin/e_comp_object.c index a6b0039..4f90b4c 100644 --- a/src/bin/e_comp_object.c +++ b/src/bin/e_comp_object.c @@ -1284,7 +1284,7 @@ _e_comp_intercept_resize(void *data, Evas_Object *obj, int w, int h) break; } if (cw->ec->internal_elm_win && (!cw->ec->moving) && (!e_client_util_resizing_get(cw->ec)) && - (!cw->ec->fullscreen) && ((!cw->ec->maximized) == E_MAXIMIZE_NONE) && + (!cw->ec->fullscreen) && (!cw->ec->maximized) && e_win_centered_get(cw->ec->internal_elm_win)) e_comp_object_util_center(obj); cw->force_move = 0; --
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: e_comp: silence warning
On Sat, 25 Jun 2016 06:37:38 -0700 Marcel Hollerbach wrote: > bu5hm4n pushed a commit to branch master. > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=a80bc133369689976c810ad4178a7528a91d1136 > > commit a80bc133369689976c810ad4178a7528a91d1136 > Author: Marcel Hollerbach > Date: Sat Jun 25 15:29:45 2016 +0200 > > e_comp: silence warning > > after talking to zmike, this is by intend. > --- > src/bin/e_comp_object.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/bin/e_comp_object.c b/src/bin/e_comp_object.c > index a495f07..a6b0039 100644 > --- a/src/bin/e_comp_object.c > +++ b/src/bin/e_comp_object.c > @@ -1284,7 +1284,7 @@ _e_comp_intercept_resize(void *data, Evas_Object *obj, > int w, int h) > break; > } > if (cw->ec->internal_elm_win && (!cw->ec->moving) && > (!e_client_util_resizing_get(cw->ec)) && > - (!cw->ec->fullscreen) && (!cw->ec->maximized == E_MAXIMIZE_NONE) && > + (!cw->ec->fullscreen) && ((!cw->ec->maximized) == E_MAXIMIZE_NONE) && I meant this line should be (!cw->ec->fullscreen) && (!cw->ec->maximized) && > e_win_centered_get(cw->ec->internal_elm_win)) > e_comp_object_util_center(obj); > cw->force_move = 0; > -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 01/01: e_comp: silence warning
bu5hm4n pushed a commit to branch master. http://git.enlightenment.org/core/enlightenment.git/commit/?id=a80bc133369689976c810ad4178a7528a91d1136 commit a80bc133369689976c810ad4178a7528a91d1136 Author: Marcel Hollerbach Date: Sat Jun 25 15:29:45 2016 +0200 e_comp: silence warning after talking to zmike, this is by intend. --- src/bin/e_comp_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bin/e_comp_object.c b/src/bin/e_comp_object.c index a495f07..a6b0039 100644 --- a/src/bin/e_comp_object.c +++ b/src/bin/e_comp_object.c @@ -1284,7 +1284,7 @@ _e_comp_intercept_resize(void *data, Evas_Object *obj, int w, int h) break; } if (cw->ec->internal_elm_win && (!cw->ec->moving) && (!e_client_util_resizing_get(cw->ec)) && - (!cw->ec->fullscreen) && (!cw->ec->maximized == E_MAXIMIZE_NONE) && + (!cw->ec->fullscreen) && ((!cw->ec->maximized) == E_MAXIMIZE_NONE) && e_win_centered_get(cw->ec->internal_elm_win)) e_comp_object_util_center(obj); cw->force_move = 0; --
Re: [E-devel] promises...
Hello, I still don't get it why promises should be an all-or-nothing thing. It must be usable for all scenarios possible or we should drop it and live with events which are impossible to translate to the real semantics of asynchronous operations (I'm calling an asynchronous operation one that returns a value asynchronously) to bindings that already have a concept of asynchronous operations. One example is making promises open to add new events through inheritance. However, let's say that it is really desirable, so we can all compromise on a middle term, we need to have a way to support that in bindings in a way that is natural in the binding languages, and IMO that is the _most_important_part_ and I have been repeating myself about this since I introduced the promise idea in january, but let me repeat again: Promises must be a way to have well-defined-semantics for bindings to be able to translate that to what is natural and native in the binding languages. The whole efl interfaces effort, afaik, is not about C API, because we already have a stable C API! We need to think about bindings too, because the efl interfaces effort is, afaik, about having usable efl interface api for bindings, which we don't have yet. We can't create bad C APIs in the process ofc, but, afaik, this is not about creating new C APIs. I work on most bindings for EFL, so yeah, I'll be very annoying about it, because I don't want to create bad bindings. I don't think anybody wants to work to do bad things, I'm not different. I want to be proud of what I deliver. And that means writing bindings that people will want to use, and not that people will curse me because they _have_ to use it. Also, I think it will help EFL a lot if we get it to be used by more languages. So, bindings already know the special relationship between derived classes of Future (I'm using cedric's nomenclature here) and translate new events directly. So I think this is doable. With the lifetime thing, well, for bindings I don't care if we drop it any automagical things because bindings will deal it correctly. So that makes things easier. Implementing data models in C might be a little less sexy, but still way easier than using events and caching all things and etc. The separation between Future and Promise, IMO, is good. About the runtime-checking, I think there's a misconception here. Eo is about runtime-checking indeed. But Eolian is about generating interfaces that are not necessarily runtime-checked. C++ is _not_ runtime-checked. So, if things belong to multiple interfaces, then it should be in two different interfaces IMO. Otherwise C++ programmers will assume they can value_set a future/promise they received from another function. And sometimes they will be right, it is not prohibited to return promise_owners and it was an idea that almost worked for genlists to get style from through events, it just didn't work because genlist must get the style synchronously and not asynchronously. So, separating the side that value_set from the side that listens to value_set makes things way clearer of the API intent. However, as long as it uses different nomenclatures in Eolian, I can separate them in C++ in generation. Regards, -- Felipe Magno de Almeida -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/enlightenment] master 01/01: e_xkb: eval group before setted to wl
bu5hm4n pushed a commit to branch master.
http://git.enlightenment.org/core/enlightenment.git/commit/?id=9c8b6a1c5d5194840116c6143804e66cbcdd3153
commit 9c8b6a1c5d5194840116c6143804e66cbcdd3153
Author: Marcel Hollerbach
Date: Sat Jun 25 01:10:01 2016 +0200
e_xkb: eval group before setted to wl
otherwise we are going to set 0 as default group.
This commit refactors out _eval_cur_group from the init timer, since wl
does not need a init timer.
---
src/bin/e_xkb.c | 44 ++--
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/src/bin/e_xkb.c b/src/bin/e_xkb.c
index 65c7018..0aa1782 100644
--- a/src/bin/e_xkb.c
+++ b/src/bin/e_xkb.c
@@ -14,25 +14,39 @@ static Ecore_Timer *save_group;
E_API int E_EVENT_XKB_CHANGED = 0;
-static Eina_Bool
-_e_xkb_init_timer(void *data)
+static void
+_eval_cur_group(void)
{
Eina_List *l;
- E_Config_XKB_Layout *cl2, *cl = data;
+ E_Config_XKB_Layout *cl2, *cl = NULL;
int cur_group = -1;
- if (!e_comp->root) return EINA_FALSE;
+ cl = e_config->xkb.current_layout;
+ if (!cl) cl = e_config->xkb.sel_layout;
+
EINA_LIST_FOREACH(e_config->xkb.used_layouts, l, cl2)
{
cur_group++;
if (!cl2->name) continue;
-if (e_config_xkb_layout_eq(cl, cl2))
+if (!cl || e_config_xkb_layout_eq(cl, cl2))
{
INF("Setting keyboard layout: %s|%s|%s", cl2->name, cl2->model,
cl2->variant);
- e_xkb_update(cur_group);
- break;
+ e_config->xkb.cur_group = cur_group;
+ return;
}
}
+ e_config->xkb.cur_group = 0;
+}
+
+static Eina_Bool
+_e_xkb_init_timer(void *data EINA_UNUSED)
+{
+ if (!e_comp->root) return EINA_FALSE;
+
+ _eval_cur_group();
+
+ e_xkb_update(e_config->xkb.cur_group);
+
return EINA_FALSE;
}
@@ -99,13 +113,12 @@ e_xkb_init(E_Pixmap_Type comp_type)
}
#endif
if (e_config->xkb.dont_touch_my_damn_keyboard) return 1;
+
_e_xkb_type_reconfig(comp_type);
- if (e_config->xkb.cur_layout)
- ecore_timer_add(1.5, _e_xkb_init_timer, e_config->xkb.current_layout);
- else if (e_config->xkb.selected_layout)
- ecore_timer_add(1.5, _e_xkb_init_timer, e_config->xkb.sel_layout);
- else if (e_config->xkb.used_layouts)
- ecore_timer_add(1.5, _e_xkb_init_timer,
eina_list_data_get(e_config->xkb.used_layouts));
+
+ if (comp_type == E_PIXMAP_TYPE_X)
+ ecore_timer_add(1.5, _e_xkb_init_timer, NULL);
+
return 1;
}
@@ -317,7 +330,10 @@ _e_xkb_type_reconfig(E_Pixmap_Type comp_type)
if (comp_type == E_PIXMAP_TYPE_X)
_e_x_xkb_reconfig();
else if (comp_type == E_PIXMAP_TYPE_WL)
- _e_wl_xkb_update(e_config->xkb.cur_group);
+ {
+_eval_cur_group();
+_e_wl_xkb_update(e_config->xkb.cur_group);
+ }
}
E_API void
--
Re: [E-devel] What is still pending for 1.18 before the freeze starts
On Fri, Jun 24, 2016 at 7:59 PM, Carsten Haitzler wrote:
> On Fri, 24 Jun 2016 07:58:44 -0500 Stephen Houston
> said:
>
>> I would like to add that the theme bugs on Genlist need fixing also. Two
>> Phab tickets in particular. 1) There is a clipping bug where, a Genlist
>> large enough to scroll, scrolls out of it's bounds and covers other widget.
>> The out of bounds content is invisible of course so you don't see it, but
>> you can still click into it. 2) Genlist tree, the row alternating colors
>> becomes messed up if a tree items children are created upon expand.
>
> 1) that's not a theme bug. it's an evas clipping/ object bug of some sort.
> 2) also not a theme bug but code bug. it just somehow doesnt re-init items
> with
> the correct edje group for odd/even.
>
>> Both of these bugs have Phab tickets. The eio monitor has a Phab ticket as
>> well and Cedric is addressing it for the release I believe.
>> On Jun 23, 2016 7:35 AM, "Stefan Schmidt" wrote:
>
> we have deeper problems. promises.
>
> right now i'm tempted to just call it quits on promises. remove them. do that
> stuff with events on objects. i'm tired of the disconnect on promises so drop
> them entirely. my patience is running thin.
Just know we will be either killing the Node.JS bindings or requiring
manual code.
People will not want to use a binding that will be written like this:
download = new efl.net.url_download('http:// ... ');
download.on('result', function () { .. });
download.on('error', function () { ... });
download.on('progress', function () { ... });
download.work(); // the async operation
This is horrible, people will expect that to work like this:
efl.net.url_download('http:// ...').then
(
function (file) // success
{
return x;
},
function (e) // error
{
},
function (p) // progress
{
}
).then( function (x) { ... });
This is what we have been advocating since the beginning, and we don't
need a huge super Eolian class to have that in all bindings, we just
need well defined semantics of asynchronous operations. We can
work with Eolian/Eo Promise for that as well and that's all _I_ ask so I
can sell EFL idea for other communities as well.
However, you wanted to have a super uber promise first and now
you just want to drop everything that even remotely allows us
the second syntax.
I have to ask, do we even care about bindings or not?
[snip]
Regards,
--
Felipe Magno de Almeida
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: elm: Always connect to wl when enforced
bu5hm4n pushed a commit to branch master.
http://git.enlightenment.org/core/efl.git/commit/?id=4de2f4a39227e7fa7d48b41794a6e8ea488f935f
commit 4de2f4a39227e7fa7d48b41794a6e8ea488f935f
Author: Marcel Hollerbach
Date: Sat Jun 25 13:06:41 2016 +0200
elm: Always connect to wl when enforced
This is a followup on ca55a920d9a5f6a4274e40fcf901a89e622c3007.
This fixes cnp/dnd for applications started outside of the weston
session. (There are still more problems with dnd and cnp)
---
src/lib/elementary/elm_config.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/lib/elementary/elm_config.c b/src/lib/elementary/elm_config.c
index 204ee34..71cf73a 100644
--- a/src/lib/elementary/elm_config.c
+++ b/src/lib/elementary/elm_config.c
@@ -3936,13 +3936,8 @@ _elm_config_sub_init(void)
{
if (!strcmp(ev, "wl")) /* and it is X11 */
{
- if (!have_wl_display) /* if there is no $DISPLAY */
- {
- ERR("$ELM_DISPLAY is set to wl but $WAYLAND_DISPLAY is not
set");
- init_wl = EINA_FALSE;
- }
- else /* if there is */
- init_wl = EINA_TRUE;
+ /* always try to connect to wl when it is enforced */
+ init_wl = EINA_TRUE;
}
else /* not wl */
init_wl = EINA_FALSE;
--
