Re: [E-devel] Ecore_processing mtdev events
I found a solution,and sorry for the late reply, I was on leave.
In evas_event_feed_multi_move() function, at the else part of
if(e-pointer.mouse_grabbed0) we have,
/* get all new in objects */
ins = evas_event_objects_event_list(e, NULL, x, y);
/* go thru old list of in objects */
copy = evas_event_list_copy(e-pointer.object.in);
EINA_LIST_FOREACH(copy, l, obj){
if (evas_object_is_in_output_rect(obj, x, y, 1, 1)
((evas_object_clippers_is_visible(obj)) ||
(obj-mouse_grabbed))
(eina_list_data_find(ins, obj))
(!evas_event_passes_through(obj))
(!evas_event_freezes_through(obj))
(!obj-clip.clipees)
((!obj-precise_is_inside) ||
(evas_object_is_inside(obj, x, y{
..
}
.
}
If you look at that - say the copy contains the objects of first
touch point, but the current event
details are for the second touch point. So
evas_object_is_in_output_rect(obj, x, y, 1, 1) fails,
as there is no such object in copy for the second touch point.
However ins contains the objects of the second touch point.
so looping ins instead of copy solves the problem.
Regards
HariHaraSudhan
On Fri, Nov 11, 2011 at 3:41 PM, Carsten Haitzler ras...@rasterman.com wrote:
On Fri, 11 Nov 2011 13:18:20 +0530 HariHara Sudhan h...@emo2.com said:
OK thank you, I think i have a lead. I will work on a solution.
let me know what's happening - i find it odd that evas would just skip events
unless it was specifically meant to - eg event happened outside that obj,
grabs
were in effect or there were no callbacks set.
On Fri, Nov 11, 2011 at 12:25 PM, Carsten Haitzler ras...@rasterman.com
wrote:
On Fri, 4 Nov 2011 20:11:12 +0530 HariHara Sudhan h...@emo2.com said:
timestamp doesn't matter. it calls the callbacks on the objects the events
are going to go to. if the mouse is grabbed (first press grabs mouse to the
objects pressed) then callbacks are reported relative to grabbed objects
until last finger is released. if (obj-callbacks) checks to see if object
has any cb's at all. if it doesn't - don't other doing anything. the target
object(s) don't have callbacks set at all. if inside your callbacks you are
deleting objects or changing their callbacks.. you may get this. if objects
are hidden, clipped out or otherwise not visible - they wont be called
either. evas is checking for geometry and visibility here for the events.
As you Said ecore process all the events, and passes on to evas.
In evas at two points events are filtered.
1. evas_event_feed_multi_move()
2.evas_object_event_callback_call()
in evas_object_event_calback_call the if(obj-callbacks) fail for
events two consecutive events at same time.
only one of them returns value the other one returns NULL.
in evas_event_feed_multi_move(), the if condition to check for
checking objects in position,visibility and etc fails for several
events.
i'm not able to find why the condition fails in both these points.
Is the reason due to pouring events for the same timestamp?
any possible solutions?
thanks in advance
Regards
HariHaraSudhan
On Fri, Nov 4, 2011 at 4:58 AM, Carsten Haitzler ras...@rasterman.com
wrote:
On Thu, 3 Nov 2011 19:36:11 +0530 HariHara Sudhan h...@emo2.com said:
Mouse gives events on a minimum of 8ms gap, but i get 2-3 touch events
within a ms.
So that is a lot of events.
But some events generated on ecore side, which are pushed into event
queue using _ecore_mouse_move are not reflected as evas_callbacks.
Some times it generates 3-4 events on ecore side but i get only one
callback on evas side.
here is the sample
evas id=2 x=578 y=66
eCore id=2 x=577 y=66
evas id=2 x=577 y=66
eCore id=2 x=577 y=65
eCore id=2 x=578 y=65
evas id=2 x=577 y=65
evas id=2 x=578 y=65
eCore id=1 x=153 y=50
eCore id=1 x=153 y=51
evas id=1 x=153 y=51
eCore id=2 x=578 y=64
eCore id=1 x=153 y=52
eCore id=2 x=578 y=65
eCore id=1 x=153 y=53
eCore id=2 x=579 y=65
eCore id=1 x=153 y=54
eCore id=2 x=579 y=66
eCore id=2 x=579 y=67
evas id=2 x=579 y=67
eCore id=1 x=153 y=55
eCore id=2 x=580 y=67
eCore id=1 x=153 y=56
eCore id=1 x=153 y=57
eCore id=1 x=152 y=57
eCore id=2 x=580 y=68
eCore id=2 x=581 y=68
this is where my problem is,a lot of ecore events are generated but on
eas side i get only few.
I couldn't find why some events are not reflected in evas_callbacks.
is there a way to process the touch events as a seperate thread in
ecore_event_procesing? or any other solution for this problem?
threads have nothing to do with this other than complicating things.
they
don't solve anything, and won't. (unless u are spending
Re: [E-devel] sound api plan
On Tue, 15 Nov 2011 04:13:32 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: I really don't know why I bother to explain these things I know will get nowhere. i've already said we can support it. i just disagree that that is a first port of call or the only port of call. i disagree that we totally reply on PA for everything we need audio-wise. Saying that what you want could be easily worked with them is also out of question, there is always the no time and bigger fish to fry, I know the drill... i've been burned before. i waited so long for xrender to go nowhere. luckily i didn't make it a core required rendering back-end. not going to depend on something like that again. if PA doesn't have the feature today - i think it's unwise to depend on it maybe having it some time in the future. that we don't provide sound feedback and he is waiting it since forever. oh that's all - yes. because no one has stepped up and done it. someone did. i said i wasn't going to do it before e17 release because i didn't want to be distracted by it. :) that is true, but we have a much bigger problem already with that and images. having a problem does not justify to introduce another ;-) Before you had 1 problem, now you'll have two. unless PA is going to get sequenced multi-track audio... we can't do everything via PA. we have a requirement for a more general solution. well.. i have a requirement. we can use PA when and where appropriate. we can use canberra when and where appropriate. i'm not going to limit designs to just what these happen to do. well not limit, because i care a lot about audio. for instance PA allows for sound what you'd like to have with images (central daemon to load stuff), but we're not using it as there is no time. Then we create something else that then we need to create something else again to match. That rule of we can always solve a problem by creating another abstraction layer. PA would not work everywhere, so create a layer to abstract it away, but that would be the role of PA :-S but it doesn't do what i want from an audio subsystem - not everything. so either i decide to limit what edje does to just what canberra does... or PA does, or i can do more if i just deal with the audio mixing locally in edje and just punt out audio stream data. this is moot if we support both paths - powerful/complex path and simple one, so where is the argument? i want to do the powerful one first as the simple one is a subset case. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] efl 1.1 alpha
i think stuff in svn is ready for an alpha set of tarballs. i've checked it all dies distcheck cleanly. does anyone have any comments here to hold up an alpha? if not - i'll rev it all up to being in an alpha state - that means versions go from 1.0.999 to 1.1.0 for example. my list is: eina eet evas ecore edje efreet e_dbus eeze bonus: evas_generic_loaders expedite cedric: did i get you right that emotion, ethumb and eio will go after this release more in line with elementary 1.0? so for this weekish.. not to worry. right? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.1 alpha
Yeah, On Tue, Nov 15, 2011 at 10:59 AM, Carsten Haitzler ras...@rasterman.com wrote: i think stuff in svn is ready for an alpha set of tarballs. i've checked it all dies distcheck cleanly. does anyone have any comments here to hold up an alpha? if not - i'll rev it all up to being in an alpha state - that means versions go from 1.0.999 to 1.1.0 for example. Yes ! my list is: eina eet evas ecore edje efreet e_dbus eeze bonus: evas_generic_loaders expedite cedric: did i get you right that emotion, ethumb and eio will go after this release more in line with elementary 1.0? so for this weekish.. not to worry. right? Yep, that's the plan. -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/edje
On Tue, 15 Nov 2011 01:15:01 -0800 Enlightenment SVN no-re...@enlightenment.org wrote: Log: edje news now up to date Author: raster snip +* lua color/text class, text, image and edje object API's You forgot to mention map, line, and polygon. -- 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 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.1 alpha
On Tue, 15 Nov 2011 18:59:06 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: i think stuff in svn is ready for an alpha set of tarballs. i've checked it all dies distcheck cleanly. does anyone have any comments here to hold up an alpha? if not - i'll rev it all up to being in an alpha state - that means versions go from 1.0.999 to 1.1.0 for example. my list is: eina eet evas ecore edje I still plan on doing an edje lua stack usage review, and write some docs. It all seems to work fine though, it's good enough for government work. B-) -- 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 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] twitter feed for commits
well first.. i put up links to our facebook, google + pages... and i also linked our twitter feed. i've set up svn commits to be able to tweet... http://www.enlightenment.org/p.php?p=support go to the twitter feed - follow if u like. developers can commit by just putting 1 line in their svn log like: tweet: Your twitter update message goes here. remember - your tweet length will be limited by twitter so don't make it long. anyway... maybe this will help with some publicity that we are actually active. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Twitter feed, Google+, Facebook pages for e
Just in case people didn't know we have a twitter feed as well as a google+ page and a facebook page for all of you who just love your social networks: http://twitter.com/_Enlightenment_ http://plus.google.com/118426816251488376359 http://www.facebook.com/enlightenment.org or just go to http://www.enlightenment.org and click on the links at the top. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] sound api plan
On Tue, Nov 15, 2011 at 6:42 AM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 15 Nov 2011 04:13:32 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: I really don't know why I bother to explain these things I know will get nowhere. i've already said we can support it. i just disagree that that is a first port of call or the only port of call. i disagree that we totally reply on PA for everything we need audio-wise. As I said, maybe not clear enough: we can't rely on PA is the worse part. We use that to motivate us to create something new out of nowhere instead of helping other freesoftware projects. The excuse is often no time and higher priority things. I know the history, if it was not this behavior then E would never exist, etc. But this is a bad practice: - what first looks like simple (20% of the work that maps to 80% of requirements), will end consuming our already scarce time (the 80% of the time that maps to 20% of requirements). This results in more work to do in the long run for a minimal initial save. If you stop to think, Embryo is an example of this, now we figured out it was better to use Lua. :-S - this mindset plays against out own project. If we stimulate people to play Not-Invented-Here syndrome, we suffer as one day we'll be the other peer. We need more people to collaborate on our code base, right? But we keep telling people it's better to start something from scratch instead of helping others! Then we have examples like turran's enesim/eon, instead of incrementally helping Evas he decided to go a different new route and we've lost a developer. :-S - relations with other projects. If you go to conferences, many developers hates us for multitude of ways (when they care to know what is E/EFL). One of the reasons is that we play the bitch and do not report or send patches, instead recreating stuff. This keeps away possible contributors as well they're not helping me, I'm not helping them. Maybe it was the case with Xrender, I don't know. Maybe it was with glib? But I'm seeing it now with PulseAudio/Canberra and I'm saying it loud :-) Particularly about the last point: I know we don't live in the wonderland. Some project maintainers are very hard to work with and changes are just rejected for no reason (hu... reminds me of our last behaviors?) and in this cases it may be worth to fork, do and prove it's right, having the possibility to merge back someday, or at least get more developers on bandwagon. Technically (I'm ignoring bureaucratic and personal reasons) maybe if it was done this way, we'd be using glib and had avoided all the work on ecore/eina, with a faster glib that could be speeding up gnome apps as well? But as the world is not 100% technical, we have to deal with persons and the line is blurry. But if we always use the excuse I'be been burned before and applying the same old rules to different people, we'll suffer. At least for Lennart, he is bit like you raster. He is hard to get along, but he does listen and will accept help. :-) Saying that what you want could be easily worked with them is also out of question, there is always the no time and bigger fish to fry, I know the drill... i've been burned before. i waited so long for xrender to go nowhere. luckily i didn't make it a core required rendering back-end. not going to depend on something like that again. if PA doesn't have the feature today - i think it's unwise to depend on it maybe having it some time in the future. PA does what a generic sound system is supposed to do. The track programming and sequencing should be done on your side, otherwise you'll be increasing complexity. But loading the samples there and requesting properties should be fine. If not, then why not help there? It is not more work, it is less. It's like sound loading. We could submit loading samples from eet. It would be nice, more projects supporting and indirectly marketing Eet! Maybe being aware of it people will use it more? that we don't provide sound feedback and he is waiting it since forever. oh that's all - yes. because no one has stepped up and done it. someone did. i said i wasn't going to do it before e17 release because i didn't want to be distracted by it. :) I did and was immediately rejected because it was not a dream-way. Maybe it is the reason it was never done before? that is true, but we have a much bigger problem already with that and images. having a problem does not justify to introduce another ;-) Before you had 1 problem, now you'll have two. unless PA is going to get sequenced multi-track audio... we can't do everything via PA. we have a requirement for a more general solution. well.. i have a requirement. we can use PA when and where appropriate. we can use canberra when and where appropriate. i'm not going to limit designs to just what these happen to do. well not limit, because i care a lot about audio. Not asking you to limit.
Re: [E-devel] sound api plan
On Tue, 15 Nov 2011 11:28:28 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Tue, Nov 15, 2011 at 6:42 AM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 15 Nov 2011 04:13:32 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: I really don't know why I bother to explain these things I know will get nowhere. i've already said we can support it. i just disagree that that is a first port of call or the only port of call. i disagree that we totally reply on PA for everything we need audio-wise. As I said, maybe not clear enough: we can't rely on PA is the worse part. We use that to motivate us to create something new out of nowhere instead of helping other freesoftware projects. The excuse is often no time and higher priority things. Actually, as much as I like Pulse Audio, and as much as I think a lot of the people that are against it just base their hatred on the early buggy versions that some distros moved to, Pulse Audio is not the be all and end all. I wont use it on my EFL embedded project for instance, but love it on my desktop. The fact that there are plenty of vocal Pulse Audio haters in the world means that we should produce something that can ALSO run on ALSA and OSS. - what first looks like simple (20% of the work that maps to 80% of requirements), will end consuming our already scarce time (the 80% of the time that maps to 20% of requirements). This results in more work to do in the long run for a minimal initial save. If you stop to think, Embryo is an example of this, now we figured out it was better to use Lua. :-S Um no. Lua is an alternative, not a replacement for embryo. In fact raster wants lua to specifically NOT be a clone of embryo. Caused me to waste some time trying to reimplement embryo in lua before he told me that. lol The project I'm using to reality check lua uses a combination of lua and embryo. -- 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 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.1 alpha
On Tue, 15 Nov 2011, Carsten Haitzler (The Rasterman) wrote: i think stuff in svn is ready for an alpha set of tarballs. i've checked it all dies distcheck cleanly. does anyone have any comments here to hold up an alpha? if not - i'll rev it all up to being in an alpha state - that means versions go from 1.0.999 to 1.1.0 for example. my list is: eina eet evas ecore edje efreet e_dbus eeze bonus: evas_generic_loaders expedite I'll plan to release evil as 1.0 at the same time, plus an SDK (as an NSIS installer) for the Windows port. Vincent -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: sanjeev IN trunk/PROTO/elev8: . data/javascript src/bin
On Tue, Nov 15, 2011 at 11:53 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Eina_xml based dbus introspection support. Thanks to Gustavo for the parser.
...
+static void cb_introspect(void *data, DBusMessage *msg, DBusError *error)
+{
+ DBusError e;
+ DBus *dbus = ((struct dbus_cache *)(data))-dbus;
+ const char *xml_str;
+
+ if ((error) (dbus_error_is_set(error)))
+ {
+ fprintf(stderr, Error: DBus replied with error %s: %s\n,
+ error-name, error-message);
convert it to eina log, create one domain for elv8 and other for
submodules such as elv8-dbus
+
+ struct DBus_Introspection_Parse_Ctxt *ctxt;
+ ctxt = (struct DBus_Introspection_Parse_Ctxt *)calloc(1, sizeof(struct
DBus_Introspection_Parse_Ctxt));
+ if (!eina_simple_xml_parse(xml_str, strlen(xml_str), EINA_TRUE, cb_parse,
ctxt))
+ {
+ fprintf(stderr, Error: could not parse XML:\n%s\n, xml_str);
leak of ctxt!
+ return;
+ }
+
+ std::pairstd::mapconst char *,DBus_Introspection_Parse_Ctxt
*::iterator,bool ret;
I'd not allocate ctxt, and would not make it into cache.
As I've explained at IRC, the correct structure for this is:
path = {interfaces, children}
children = [path1, path2, ...]
interfaces = [interface1, interface2, ...]
interface = {methods, signals, properties}
methods = [method1, method2, method3...]
method = {name, [argument1, argument2, ...]}
signals = [signal1, signal2, signal3...]
signal = {name, [argument1, argument2, ...]}
properties = [property1, property2, property3...]
property = {name, type}
Usage is one of:
1 - explicit:
var obj = bus.get_object(name, path);
var iface = obj.get_interface(iface_name);
iface.Method(p1, p2, p3);
2 - implicit:
var obj = bus.get_object(name, path);
obj.Method(p1, p2, p3);
The first case is simple:
iface = find_interface(iface_name) # mapping string = interface structure
method = find_method(iface, signature) # mapping string =
method structure
signature you need to compute for instance:
ai Method(o,s,i)
ai Method(o,s,name=value) # named values will be supported in
elev8? parameters in a hash/map? Must define a policy, like sort
alphabetically and put at the end. Likely will have to have multiple
signatures per method!
The second case is bit more complex:
ifaces = get_all_interfaces(obj) # mapping path = list of iface
structures
methods = []
for i in ifaces:
m = find_method(i, signature) # mapping string = method structure
if not m:
continue
methods.append(m)
if len(methods) 1:
raise Error: conflicting interfaces for + signature + :
+ , .join(ifaces)
else if len(methods) == 0:
raise Error: unknown method
method = methods[0]
Cache: method lookup is likely expensive, then cache it as LRU per
object, with a limit of dozens so you don't leak memory. Test case
must not go the slow path after the first iteration:
for (i = 0; i 1000; i++)
obj.Method(i);
Assuming that services are implemented correctly the interfaces are
unique globally, then you can have:
global map interfaces: interface name string = interface
interface map methods: method signature string = method
object list interfaces: pair (interface name string, interface
instance interface)
object lru methods: pair (method signature string, method
instance method)
===
--- trunk/PROTO/elev8/src/bin/dbus_library.h 2011-11-15 13:34:28 UTC (rev
65263)
+++ trunk/PROTO/elev8/src/bin/dbus_library.h 2011-11-15 13:53:27 UTC (rev
65264)
@@ -4,21 +4,100 @@
#include v8.h
#include dbus/dbus.h
#include E_DBus.h
-#include dbus_introspect.h
+#include Eina.h
+
#include exception
-#include sstream
+#include map
#include iostream
#include fstream
+/* memory efficient structures to hold introspection information.
+ * maybe Eina_Inlist could be replaced with single array of structures
+ * (not to be confused with Eina_Array)
+ */
+
+struct DBus_Method_Argument
+{
+ EINA_INLIST;
+ const char *type;
+ const char *name;
+ Eina_Bool is_output:1;
+};
if you're using structs with malloc/free (C-like) then declare as
extern C {}, will avoid name marshling by C++ compiler, etc.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
Re: [E-devel] twitter feed for commits
On Tue, 15 Nov 2011 21:17:40 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: well first.. i put up links to our facebook, google + pages... and i also linked our twitter feed. i've set up svn commits to be able to tweet... http://www.enlightenment.org/p.php?p=support go to the twitter feed - follow if u like. developers can commit by just putting 1 line in their svn log like: tweet: Your twitter update message goes here. remember - your tweet length will be limited by twitter so don't make it long. anyway... maybe this will help with some publicity that we are actually active. hmm so all e devs are anonymous when using this feature. fantastic. -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Facebook : Enligthenment France
Hey there is also an Enlightenment France facebook page: http://www.facebook.com/profile.php?id=12934562239 can someone add it to the main web site too ? thank you Vincent -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.1 alpha
On 11/15/2011 10:59 AM, Carsten Haitzler (The Rasterman) wrote: i think stuff in svn is ready for an alpha set of tarballs. i've checked it all dies distcheck cleanly. does anyone have any comments here to hold up an alpha? if not - i'll rev it all up to being in an alpha state - that means versions go from 1.0.999 to 1.1.0 for example. Just remember to make the next version 1.1.99 for the OS X people. S. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl 1.1 alpha
2011/11/15 Sebastian Dransfeld s...@tango.flipp.net: On 11/15/2011 10:59 AM, Carsten Haitzler (The Rasterman) wrote: i think stuff in svn is ready for an alpha set of tarballs. i've checked it all dies distcheck cleanly. does anyone have any comments here to hold up an alpha? if not - i'll rev it all up to being in an alpha state - that means versions go from 1.0.999 to 1.1.0 for example. Just remember to make the next version 1.1.99 for the OS X people. S. I will be there to check :) -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Facebook : Enligthenment France
There is also a Greek group. https://www.facebook.com/groups/127149362812/ can this also be added alongside the others? thank you, -- Regards, Alex-P. Natsios (a.k.a Drakevr) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: sanjeev IN trunk/PROTO/elev8: . data/javascript src/bin
On Tue, Nov 15, 2011 at 11:45 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Tue, Nov 15, 2011 at 11:53 AM, Enlightenment SVN
no-re...@enlightenment.org wrote:
Log:
Eina_xml based dbus introspection support. Thanks to Gustavo for the
parser.
...
+static void cb_introspect(void *data, DBusMessage *msg, DBusError
*error)
+{
+ DBusError e;
+ DBus *dbus = ((struct dbus_cache *)(data))-dbus;
+ const char *xml_str;
+
+ if ((error) (dbus_error_is_set(error)))
+ {
+fprintf(stderr, Error: DBus replied with error %s: %s\n,
+error-name, error-message);
convert it to eina log, create one domain for elv8 and other for
submodules such as elv8-dbus
Ok.
+
+ struct DBus_Introspection_Parse_Ctxt *ctxt;
+ ctxt = (struct DBus_Introspection_Parse_Ctxt *)calloc(1,
sizeof(struct DBus_Introspection_Parse_Ctxt));
+ if (!eina_simple_xml_parse(xml_str, strlen(xml_str), EINA_TRUE,
cb_parse, ctxt))
+ {
+fprintf(stderr, Error: could not parse XML:\n%s\n, xml_str);
leak of ctxt!
Will fix this.
+return;
+ }
+
+ std::pairstd::mapconst char *,DBus_Introspection_Parse_Ctxt
*::iterator,bool ret;
I'd not allocate ctxt, and would not make it into cache.
As I've explained at IRC, the correct structure for this is:
path = {interfaces, children}
children = [path1, path2, ...]
interfaces = [interface1, interface2, ...]
interface = {methods, signals, properties}
methods = [method1, method2, method3...]
method = {name, [argument1, argument2, ...]}
signals = [signal1, signal2, signal3...]
signal = {name, [argument1, argument2, ...]}
properties = [property1, property2, property3...]
property = {name, type}
Don't the existing structures do this already? Except for the addition of
the DBus_Node?
Usage is one of:
1 - explicit:
var obj = bus.get_object(name, path);
var iface = obj.get_interface(iface_name);
iface.Method(p1, p2, p3);
2 - implicit:
var obj = bus.get_object(name, path);
obj.Method(p1, p2, p3);
I haven't yet decided on the best way to make dbus calls/signals simple for
users. Let's discuss over IRC today.
The first case is simple:
iface = find_interface(iface_name) # mapping string = interface
structure
method = find_method(iface, signature) # mapping string =
method structure
signature you need to compute for instance:
ai Method(o,s,i)
ai Method(o,s,name=value) # named values will be supported in
elev8? parameters in a hash/map? Must define a policy, like sort
alphabetically and put at the end. Likely will have to have multiple
signatures per method!
The second case is bit more complex:
ifaces = get_all_interfaces(obj) # mapping path = list of iface
structures
methods = []
for i in ifaces:
m = find_method(i, signature) # mapping string = method structure
if not m:
continue
methods.append(m)
if len(methods) 1:
raise Error: conflicting interfaces for + signature + :
+ , .join(ifaces)
else if len(methods) == 0:
raise Error: unknown method
method = methods[0]
Cache: method lookup is likely expensive, then cache it as LRU per
object, with a limit of dozens so you don't leak memory. Test case
must not go the slow path after the first iteration:
for (i = 0; i 1000; i++)
obj.Method(i);
Assuming that services are implemented correctly the interfaces are
unique globally, then you can have:
global map interfaces: interface name string = interface
interface map methods: method signature string = method
object list interfaces: pair (interface name string, interface
instance interface)
object lru methods: pair (method signature string, method
instance method)
===
--- trunk/PROTO/elev8/src/bin/dbus_library.h2011-11-15 13:34:28 UTC
(rev 65263)
+++ trunk/PROTO/elev8/src/bin/dbus_library.h2011-11-15 13:53:27 UTC
(rev 65264)
@@ -4,21 +4,100 @@
#include v8.h
#include dbus/dbus.h
#include E_DBus.h
-#include dbus_introspect.h
+#include Eina.h
+
#include exception
-#include sstream
+#include map
#include iostream
#include fstream
+/* memory efficient structures to hold introspection information.
+ * maybe Eina_Inlist could be replaced with single array of structures
+ * (not to be confused with Eina_Array)
+ */
+
+struct DBus_Method_Argument
+{
+ EINA_INLIST;
+ const char *type;
+ const char *name;
+ Eina_Bool is_output:1;
+};
if you're using structs with malloc/free (C-like) then declare as
extern C {}, will avoid name marshling by C++ compiler, etc.
Yes, will fix this.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
Re: [E-devel] Facebook : Enligthenment France
In svn ! Nothing from Brazil btw ? On Tue, Nov 15, 2011 at 9:34 PM, Alex-P. Natsios apnats...@gmail.com wrote: There is also a Greek group. https://www.facebook.com/groups/127149362812/ can this also be added alongside the others? thank you, -- Regards, Alex-P. Natsios (a.k.a Drakevr) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Cedric BAIL -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Facebook : Enligthenment France
On Tue, Nov 15, 2011 at 7:41 PM, Cedric BAIL cedric.b...@free.fr wrote: In svn ! Nothing from Brazil btw ? We're not social! -- Eduardo de Barros Lima ebl...@gmail.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Where was the developer list gone in our website?
Hi, At this time, the active developer list is not shown in our enlightenment website. What happens there? -Regards, Hermet- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Facebook : Enligthenment France
On Tue, Nov 15, 2011 at 8:00 PM, Eduardo Lima (Etrunko) ebl...@gmail.com wrote: On Tue, Nov 15, 2011 at 7:41 PM, Cedric BAIL cedric.b...@free.fr wrote: In svn ! Nothing from Brazil btw ? We're not social! http://www.facebook.com/enlightenment.br done -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] sound api plan
On Tue, 15 Nov 2011 11:28:28 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Tue, Nov 15, 2011 at 6:42 AM, Carsten Haitzler ras...@rasterman.com wrote: On Tue, 15 Nov 2011 04:13:32 -0200 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: I really don't know why I bother to explain these things I know will get nowhere. i've already said we can support it. i just disagree that that is a first port of call or the only port of call. i disagree that we totally reply on PA for everything we need audio-wise. As I said, maybe not clear enough: we can't rely on PA is the worse part. We use that to motivate us to create something new out of nowhere instead of helping other freesoftware projects. The excuse is often no time and higher priority things. I know the history, if it was not this behavior then E would never exist, etc. But this is a bad practice: - what first looks like simple (20% of the work that maps to 80% of requirements), will end consuming our already scarce time (the 80% of the time that maps to 20% of requirements). This results in more work to do in the long run for a minimal initial save. If you stop to think, Embryo is an example of this, now we figured out it was better to use Lua. :-S actually i've spent more time on lua than embryo. much more. embryo still is massively smaller and leaner too. lua also still can't abort execution with infinite loops. embryo can. and let me be clear... EMBRYO WAS BASED ON ANOTHER OPEN SOURCE PROJECT... EXACTLY YOUR ARGUMENT. i didn't write it. the compiler is sill 99% the same as where it came from. i did almost rewrite the entire runtime vm though. and it got a lot smaller in the process. my REQUIREMENTS were i need something that does: if (x) then do y else do z. that was it. embryo met and exceeded that by a vast vast vast margin. at the time it was a choice of write my own mini logic engine inside edje or re-use another one. i re-used an open source project. i chose the one that had the lowest footprint and least intrusiveness as i wasn't in the mood for having a big fat execution environment. - this mindset plays against out own project. If we stimulate people to play Not-Invented-Here syndrome, we suffer as one day we'll be the other peer. We need more people to collaborate on our code base, right? But we keep telling people it's better to start something from scratch instead of helping others! Then we have examples like turran's enesim/eon, instead of incrementally helping Evas he decided to go a different new route and we've lost a developer. :-S that has nothing to do with this topic at all. - relations with other projects. If you go to conferences, many developers hates us for multitude of ways (when they care to know what is E/EFL). One of the reasons is that we play the bitch and do not report or send patches, instead recreating stuff. This keeps away possible contributors as well they're not helping me, I'm not helping them. Maybe it was the case with Xrender, I don't know. Maybe it was with glib? But I'm seeing it now with PulseAudio/Canberra and I'm saying it loud :-) and for audio we're using another open source projct that actually DOES have the features we want. in fact using 4 of them. libogg, libflac, libsndfile and libremix... if you didn't notice. maybe you're just upset we're not using your project of choice. as for xrender... that'd involve a massive detour into the internals of x - at the time pixman wasn't even a library. making any changes would involve recompiling and restarting xservers. no better way for e to have been delayed by years. not to mention having to work on multiple drivers too. Particularly about the last point: I know we don't live in the wonderland. Some project maintainers are very hard to work with and changes are just rejected for no reason (hu... reminds me of our last behaviors?) and in this cases it may be worth to fork, do and prove it's right, having the possibility to merge back someday, or at least get more developers on bandwagon. and if we fork pulse and then require the new features we have - we have a competing pulse that people have to replace their existing installation of, which invariably no one will do, so we're stuck with the lowest common denominator. i'm sitting and staring at a library that already meets our needs. you just don't like that. Technically (I'm ignoring bureaucratic and personal reasons) maybe if it was done this way, we'd be using glib and had avoided all the work on ecore/eina, with a faster glib that could be speeding up gnome apps as well? after having fought day in and out within the gnome dev world i wasn't going to touch it. i spent a year of my life being told i was wrong only in the end to be told shit. you're right. help!. too late. i wasn't going to use glib at all because i already saw things i didn't like - i didn't like the timers using sec+msec vals - a
Re: [E-devel] twitter feed for commits
On Tue, 15 Nov 2011 11:12:52 -0500 Mike Blumenkrantz m...@zentific.com said: On Tue, 15 Nov 2011 21:17:40 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: well first.. i put up links to our facebook, google + pages... and i also linked our twitter feed. i've set up svn commits to be able to tweet... http://www.enlightenment.org/p.php?p=support go to the twitter feed - follow if u like. developers can commit by just putting 1 line in their svn log like: tweet: Your twitter update message goes here. remember - your tweet length will be limited by twitter so don't make it long. anyway... maybe this will help with some publicity that we are actually active. hmm so all e devs are anonymous when using this feature. fantastic. the link at the end points to your commit. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Where was the developer list gone in our website?
On Wed, 16 Nov 2011 09:23:49 +0900 ChunEon Parkher...@naver.com said: fixed. Hi, At this time, the active developer list is not shown in our enlightenment website. What happens there? -Regards, Hermet- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Where was the developer list gone in our website?
Thank you! :) -Regards, Hermet- -Original Message- From: Carsten Haitzlerlt;ras...@rasterman.comgt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt; Cc: ChunEon Parklt;her...@naver.comgt; Sent: 11-11-16(수) 13:13:44 Subject: Re: [E-devel] Where was the developer list gone in our website? On Wed, 16 Nov 2011 09:23:49 +0900 ChunEon Parklt;her...@naver.comgt; said: fixed. Hi, At this time, the active developer list is not shown in our enlightenment website. What happens there? -Regards, Hermet- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ 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 -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] New EFL release cycle 1.1/1.5 ALPHA
We'd like to announce a new release cycle alpha release of several Enlightenment components http://download.enlightenment.org/releases/eina-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/eina-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/eet-1.5.0-alpha.tar.gz http://download.enlightenment.org/releases/eet-1.5.0-alpha.tar.bz2 http://download.enlightenment.org/releases/evas-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/evas-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/ecore-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/ecore-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/embryo-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/embryo-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/edje-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/edje-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/efreet-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/efreet-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/e_dbus-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/e_dbus-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/eeze-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/eeze-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/expedite-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/expedtie-1.1.0-alpha.tar.bz2 http://download.enlightenment.org/releases/evas_generic_loaders-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/evas_generic_loaders-1.1.0-alpha.tar.bz2 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk: e_dbus ecore edje eet eeze efreet eina embryo evas evas/m4 evas_generic_loaders expedite
On Tue, 15 Nov 2011, Enlightenment SVN wrote:
Log:
update release candidate trees to their release version in preparation
for alpha
so, I have to update evil and make these EFL depend on evil 1.0.0 ?
Vincent
Author: raster
Date: 2011-11-15 21:34:37 -0800 (Tue, 15 Nov 2011)
New Revision: 65280
Trac: http://trac.enlightenment.org/e/changeset/65280
Modified:
trunk/e_dbus/configure.ac trunk/ecore/configure.ac trunk/edje/configure.ac
trunk/eet/configure.ac trunk/eeze/configure.ac trunk/efreet/configure.ac
trunk/eina/configure.ac trunk/embryo/configure.ac trunk/evas/configure.ac
trunk/evas/m4/evas_check_engine.m4 trunk/evas/m4/evas_check_loader.m4
trunk/evas_generic_loaders/configure.ac trunk/expedite/configure.ac
Modified: trunk/e_dbus/configure.ac
===
--- trunk/e_dbus/configure.ac 2011-11-16 04:11:45 UTC (rev 65279)
+++ trunk/e_dbus/configure.ac 2011-11-16 05:34:37 UTC (rev 65280)
@@ -1,12 +1,12 @@
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
m4_define([v_maj], [1])
-m4_define([v_min], [0])
-m4_define([v_mic], [999])
+m4_define([v_min], [1])
+m4_define([v_mic], [0])
m4_define([v_rev], m4_esyscmd([(svnversion ${SVN_REPO_PATH:-.} | grep -v
export || echo 0) | awk -F : '{printf(%s\n, $1);}' | tr -d ' :MSP\n']))
m4_if(v_rev, [0], [m4_define([v_rev], m4_esyscmd([git log 2 /dev/null |
(grep -m1 git-svn-id || echo 0) | sed -e 's/.*@\([0-9]*\).*/\1/' | tr -d
'\n']))])
##-- When released, remove the dnl on the below line
-dnl m4_undefine([v_rev])
+m4_undefine([v_rev])
##-- When doing snapshots - change soname. remove dnl on below line
dnl m4_define([relname], [ver-pre-svn-07])
dnl m4_define([v_rel], [-release relname])
@@ -81,13 +81,13 @@
;;
esac
-requirement_ebluez=edbus = 1.0.0
-requirement_econnman=edbus = 1.0.0
-requirement_edbus=ecore = 1.0.0 eina = 1.0.0 dbus-1 = 0.62
-requirement_ehal=edbus = 1.0.0
-requirement_enotify=edbus = 1.0.0
-requirement_eofono=edbus = 1.0.0
-requirement_eukit=edbus = 1.0.0
+requirement_ebluez=edbus = 1.1.0
+requirement_econnman=edbus = 1.1.0
+requirement_edbus=ecore = 1.1.0 eina = 1.1.0 dbus-1 = 0.62
+requirement_ehal=edbus = 1.1.0
+requirement_enotify=edbus = 1.1.0
+requirement_eofono=edbus = 1.1.0
+requirement_eukit=edbus = 1.1.0
requirement_dbus=dbus-1 = 0.62
### Additional options to configure
@@ -152,7 +152,7 @@
dbus_cflags=$DBUS_CFLAGS
AC_SUBST(dbus_libs)
AC_SUBST(dbus_cflags)
-PKG_CHECK_MODULES([EDBUS], [ecore = 1.0.0 eina = 1.0.0 dbus-1 = 0.62])
+PKG_CHECK_MODULES([EDBUS], [ecore = 1.1.0 eina = 1.1.0 dbus-1 = 0.62])
# Find out the version of DBUS we're using
dbus_version=`pkg-config --modversion dbus-1`
@@ -180,8 +180,8 @@
# Dependencies for the libraries
if test x${enable_enotify} = xyes ; then
PKG_CHECK_MODULES([EVAS],
- [evas = 1.0.0],
- [requirement_enotify=evas = 1.0.0 ${requirement_enotify}],
+ [evas = 1.1.0],
+ [requirement_enotify=evas = 1.1.0 ${requirement_enotify}],
[enable_enotify=no])
fi
@@ -206,63 +206,63 @@
if test x${have_edbus_test} = xyes ; then
PKG_CHECK_MODULES([EDBUS_TEST],
- [ecore = 1.0.0 dbus-1 = 0.62],
+ [ecore = 1.1.0 dbus-1 = 0.62],
[have_edbus_test=yes],
[have_edbus_test=no])
fi
if test x${have_edbus_test_client} = xyes ; then
PKG_CHECK_MODULES([EDBUS_TEST_CLIENT],
- [ecore = 1.0.0 dbus-1 = 0.62],
+ [ecore = 1.1.0 dbus-1 = 0.62],
[have_edbus_test_client=yes],
[have_edbus_test_client=no])
fi
if test x${have_edbus_bluez_test} = xyes ; then
PKG_CHECK_MODULES([EDBUS_BLUEZ_TEST],
- [ecore = 1.0.0 eina = 1.0.0 dbus-1 = 0.62],
+ [ecore = 1.1.0 eina = 1.1.0 dbus-1 = 0.62],
[have_edbus_bluez_test=yes],
[have_edbus_bluez_test=no])
fi
if test x${have_edbus_connman_test} = xyes ; then
PKG_CHECK_MODULES([EDBUS_CONNMAN_TEST],
- [ecore = 1.0.0 eina = 1.0.0 dbus-1 = 0.62],
+ [ecore = 1.1.0 eina = 1.1.0 dbus-1 = 0.62],
[have_edbus_connman_test=yes],
[have_edbus_connman_test=no])
fi
if test x${have_edbus_notification_daemon_test} = xyes ; then
PKG_CHECK_MODULES([EDBUS_NOTIFICATION_DAEMON_TEST],
- [ecore = 1.0.0 evas = 1.0.0 eina = 1.0.0 dbus-1 = 0.62],
+ [ecore = 1.1.0 evas = 1.1.0 eina = 1.1.0 dbus-1 = 0.62],
[have_edbus_notification_daemon_test=yes],
[have_edbus_notification_daemon_test=no])
fi
if test x${have_edbus_notify_send} = xyes ; then
PKG_CHECK_MODULES([EDBUS_NOTIFY_SEND],
- [ecore = 1.0.0 evas = 1.0.0 eina = 1.0.0 dbus-1 = 0.62],
+ [ecore = 1.1.0 evas = 1.1.0 eina = 1.1.0 dbus-1 = 0.62],
[have_edbus_notify_send=yes],
[have_edbus_notify_send=no])
fi
if test x${have_edbus_notify_test} = xyes ; then
PKG_CHECK_MODULES([EDBUS_NOTIFY_TEST],
- [ecore =
Re: [E-devel] E SVN: raster trunk/expedite
Hello. On Tue, 2011-11-15 at 22:13, Enlightenment SVN wrote: Log: fix to 1.0.0 not 0.1.0 for expedite alpha! Author: raster Date: 2011-11-15 22:13:09 -0800 (Tue, 15 Nov 2011) New Revision: 65282 Trac: http://trac.enlightenment.org/e/changeset/65282 Modified: trunk/expedite/configure.ac Modified: trunk/expedite/configure.ac === --- trunk/expedite/configure.ac 2011-11-16 06:07:37 UTC (rev 65281) +++ trunk/expedite/configure.ac 2011-11-16 06:13:09 UTC (rev 65282) @@ -3,7 +3,7 @@ # get rid of that stupid cache mechanism rm -f config.cache -AC_INIT([expedite], [0.1.0], [enlightenment-devel@lists.sourceforge.net]) +AC_INIT([expedite], [1.1.0], [enlightenment-devel@lists.sourceforge.net]) Log messages says fix to 1.0.0 but you fixed it to 1.1.0 :) regards Stefan Schmidt -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New EFL release cycle 1.1/1.5 ALPHA
We'd like to announce a new release cycle alpha release of several Enlightenment components http://download.enlightenment.org/releases/expedite-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/expedtie-1.1.0-alpha.tar.bz2 expedtie? S. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] New EFL release cycle 1.1/1.5 ALPHA
On Wed, 16 Nov 2011 08:30:19 +0100 s...@tango.flipp.net wrote: We'd like to announce a new release cycle alpha release of several Enlightenment components http://download.enlightenment.org/releases/expedite-1.1.0-alpha.tar.gz http://download.enlightenment.org/releases/expedtie-1.1.0-alpha.tar.bz2 expedtie? S. we have our first bug! -- Mike Blumenkrantz Zentific: Doctor recommended, mother approved. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
