[E-devel] Deprecating Ecore_Desktop
All, We've had Efreet in CVS for a while now and it seems to be working well. Taking a look at the other apps in CVS the only one still using Ecore_Desktop that I noticed was Engage. Can the Engage maintainer please update the app to use Efreet so we can move Ecore_Desktop over into proto? Thanks, dan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] image loading questions
Cool, glad to hear you guys think memory loading is a sane idea! haha, that is funny that we came up with the same plan, CodeWarrior. I'll try to come on IRC sometime again to disucss it further. :) On 7/16/07, Cedric BAIL [EMAIL PROTECTED] wrote: On Monday 16 July 2007 12:26:51 Hisham Mardam Bey wrote: On 7/15/07, Eric Wasylishen [EMAIL PROTECTED] wrote: Hi, I have a few questions related image loading. One thing I'm working on is an xmms2 client using ETK/evolve. I'd like it to show album cover art; the way the xmms2 client lib handles this is it gives you a pointer to an image file that was copied in to memory but not decoded. People using gtk have a function in gdk_pixbuf for this, which automatically determines the image format (probably jpg or png for covers) and decodes it, but as far as I can tell imlib2/evas lack this feature? (though I noticed epeg can load a jpeg file from memory.) One option I though of is just copying the loader code for say JPG and PNG from evas or imlib2 in to my app, and modifying it to do what I need. Or, would loading images from memory be useful enough to go in evas or imlib2? Would be nice to have in evas. Definitively. I started looking at this and only wrote a patch for eet. This patch add a new eet_memopen_read. So you can add eet file also to your idea :) Cedric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On 7/14/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote:
On 7/14/07, Lars Munch [EMAIL PROTECTED] wrote:
Hi Gustavo
On Fri, Jul 13, 2007 at 07:53:58PM -0300, Gustavo Sverzut Barbieri
wrote:
Ok, reading evas docs it's really the expected behavior, at least it's
documented:
* EVAS_CALLBACK_MOUSE_OUT: event_info = pointer to
Evas_Event_Mouse_Out * * ... Note that no out events will be *
reported if the mouse pointer is implicitly grabbed to an object (the
* mouse buttons are down at all and any were pressed on that object).
An * out event will be reported as soon as the mouse is no longer
grabbed (no * mouse buttons are depressed). Out events will be
reported once all buttons * are released, if the mouse has left the
object.
So, how to solve it without brake every existent thing that depends on
this?
As you can see from this post I had a similar problem some months ago:
http://article.gmane.org/gmane.comp.window-managers.enlightenment.devel/12444/match=
I was also creating a virtual keyboard for a touchscreen and it was also
highly inspirred by the iPhone keyboard.
I think the current behaviour are good for some parts like sliders, but
for other pars like push buttons I would like to be able to get an out
event as soon at the mouse leaves the part (clicked or not). Maybe we
could add an ungrab or regrab function?
yes, maybe mouse_grab=0|1 and in evas test for this flag being set.
BUT, i already tried a quick hack to avoid mouse_grabbed lines and it
didn't work, maybe it's not that easy or I did some mistake, again a
_quick_ hack :-P
Ok, it turned out to be easy to extend this with mouse_grab idea, I'd
like some review on these patches, but I've tested them together with
an etk application (edje_viewer) and it seems to work fine.
Patches are attached as TXT so gmail recognizes them as text/plain and
avoid them being stripped by e-devel mail list.
Notice that edje property is no_mouse_grab, because then we can keep
compatibility with existent .edj files.
I don't like evas_object_mouse_grab_set() very much, it looks like
mouse will be immediately grab, which is not the case. But I don't
have any better word for that.
--
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
? configure.addopts
? configure.addopts-i686
Index: src/lib/Evas.h
===
RCS file: /var/cvs/e/e17/libs/evas/src/lib/Evas.h,v
retrieving revision 1.100
diff -u -p -r1.100 Evas.h
--- src/lib/Evas.h 10 Jul 2007 00:13:25 - 1.100
+++ src/lib/Evas.h 17 Jul 2007 21:08:04 -
@@ -766,6 +766,9 @@ extern C {
EAPI Evas_Bool evas_object_repeat_events_get (Evas_Object *obj);
EAPI void evas_object_propagate_events_set (Evas_Object *obj,
Evas_Bool prop);
EAPI Evas_Bool evas_object_propagate_events_get (Evas_Object *obj);
+ EAPI void evas_object_mouse_grab_set(Evas_Object *obj,
Evas_Bool no_mouse_grab);
+ EAPI Evas_Bool evas_object_mouse_grab_get(Evas_Object *obj);
+
EAPI void evas_object_event_callback_add(Evas_Object *obj,
Evas_Callback_Type type, void (*func) (void *data, Evas *e, Evas_Object *obj,
void *event_info), const void *data);
EAPI void *evas_object_event_callback_del(Evas_Object *obj,
Evas_Callback_Type type, void (*func) (void *data, Evas *e, Evas_Object *obj,
void *event_info));
Index: src/lib/canvas/evas_callbacks.c
===
RCS file: /var/cvs/e/e17/libs/evas/src/lib/canvas/evas_callbacks.c,v
retrieving revision 1.31
diff -u -p -r1.31 evas_callbacks.c
--- src/lib/canvas/evas_callbacks.c 30 Apr 2007 04:22:42 - 1.31
+++ src/lib/canvas/evas_callbacks.c 17 Jul 2007 21:08:04 -
@@ -218,12 +218,13 @@ evas_object_event_callback_call(Evas_Obj
* EVAS_CALLBACK_MOUSE_DOWN: event_info = pointer to Evas_Event_Mouse_Down
*
* This event is triggered by a mouse button being depressed while over an
- * object. This causes this object to passively grab the mouse until all mouse
- * buttons have been released. That means if this mouse button is the first to
- * be pressed, all future mouse events will be reported to only this object
- * until no buttons are down. That includes mouse move events, in and out
- * events, and further button presses. When all buttons are released, event
- * propagation occurs as normal.
+ * object. If mouse_grab is true (default) this causes this object to
+ * passively grab the mouse until all mouse buttons have been released.
+ * That means if this mouse button is the first to be pressed, all future
+ * mouse events will be reported to only this object until no buttons are
+ * down. That includes mouse move events, in and out events,
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: Notice that edje property is no_mouse_grab, because then we can keep compatibility with existent .edj files. I don't like evas_object_mouse_grab_set() very much, it looks like mouse will be immediately grab, which is not the case. But I don't have any better word for that. snip + EAPI void evas_object_mouse_grab_set(Evas_Object *obj, Evas_Bool no_mouse_grab); + EAPI Evas_Bool evas_object_mouse_grab_get(Evas_Object *obj); Maybe evas_object_auto_grab_set(Evas_Object *obj, Evas_Bool auto_grab) ? (or _mouse_auto_grab_) Whatever we call it, the second parameter should NOT be no_*. It should be TRUE for grab the mouse, and simply default to TRUE. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On 7/18/07, Brian Mattern [EMAIL PROTECTED] wrote: On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: Notice that edje property is no_mouse_grab, because then we can keep compatibility with existent .edj files. I don't like evas_object_mouse_grab_set() very much, it looks like mouse will be immediately grab, which is not the case. But I don't have any better word for that. snip + EAPI void evas_object_mouse_grab_set(Evas_Object *obj, Evas_Bool no_mouse_grab); + EAPI Evas_Bool evas_object_mouse_grab_get(Evas_Object *obj); Maybe evas_object_auto_grab_set(Evas_Object *obj, Evas_Bool auto_grab) ? (or _mouse_auto_grab_) it's not that better... other suggestions? can_grab_mouse? Whatever we call it, the second parameter should NOT be no_*. It should be TRUE for grab the mouse, and simply default to TRUE. yes, I agree, but how about edje files? Can I rely on people updating their edje files? Remember that edje files will not be recompiled since they have not changed, users may issue make clean to get it updated. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: On 7/14/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Ok, it turned out to be easy to extend this with mouse_grab idea, I'd like some review on these patches, but I've tested them together with an etk application (edje_viewer) and it seems to work fine. Patches are attached as TXT so gmail recognizes them as text/plain and avoid them being stripped by e-devel mail list. Notice that edje property is no_mouse_grab, because then we can keep compatibility with existent .edj files. Can't you just call it mouse_grab and default it to 1 to keep compatibility? Regards Lars Munch - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On 7/18/07, Lars Munch [EMAIL PROTECTED] wrote: On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: On 7/14/07, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Ok, it turned out to be easy to extend this with mouse_grab idea, I'd like some review on these patches, but I've tested them together with an etk application (edje_viewer) and it seems to work fine. Patches are attached as TXT so gmail recognizes them as text/plain and avoid them being stripped by e-devel mail list. Notice that edje property is no_mouse_grab, because then we can keep compatibility with existent .edj files. Can't you just call it mouse_grab and default it to 1 to keep compatibility? except that when it's not present in eet file (.edj) it will return 0. thus you can default it to be 1 if omitted during compile (edje_cc), but not while reading (file_set)... at least this is my understanding, I based my code on mouse_events, which is 1 by default. -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Nightly builds - Was: Is this a community project?
On Tue, 17 Jul 2007 10:14:58 +1000 David Seikel [EMAIL PROTECTED] babbled: Attached is the result of a first cut at a nightly build script. Early days, baby steps, don't pick over the little details. We can start with the basics and work up to more features later. For now I can run this on my boxen while it gets developed further. Move it to the E servers and volunteer boxen when it's more mature. Currently it only compiles stuff that uses autofoo. Some things are skipped, mostly due to being deprecated or broken and unmantained. Most of what is skipped is in misc. Everything in e17, misc, and e_modules is included except for the e17/test and e17/docs directories. can you... put the script in cvs somewhere? tough to talk about something we can't see. Do we need more information, less information, actual build logs to be stored somewhere, etc? Throw in e16, eterm, e17/test, and e17/docs just for completion? personally - i think this needs an explicit list of things to build (and thus the order to build them in). doing it as a user is trivial - just need to do a --prefix=/path/to/user/owned/dir in configure. the rest is just a matter of $PKG_CONFIG_PATH, $PATH, $LD_LIBRARY_PATH then cvs update -dP for I in `cat build-list`; do build.sh; done build.log and a build.sh (or a shell func) that runs the autogen.sh, make and make install with a low priority with nice + ionice. the build log doesn't need to be fancy or pretty - just needs to be all the raw output of the whole build. I think a nightly email to this list would be the most useful, just stashing the results away on the web somewhere makes it too easy to ignore. don't even think we need that much - just stashing the results in a web page somewhere is enough For the curious, I'm modifying easy_e17.sh to do this, as I'm very familiar with it. I've discussed this with morlenxus, and we have agreed to add a few things to easy_e17.sh to make it better for this type of work. TODO - Remove need to be root/use sudo. Support things that don't use the autofoo three step. Add qemu / scratchbox support for hardware / OSs we don't have test boxen for. Maybe create .rpm files on RPM based distros and .deb files on Debian based distros. BTW, while on the subject of automated testing, I've been asked if E17 supports accessibility stuff. Apparently he wanted to use a particular automated GUI test system that uses that. As far as I know, we do not support that. Any thoughts? you will need to be more specific with supports accessibility stuff. e make no particular efforts one way or another for accessibility. if something works or not depends on the details of what it does. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Issue with Emotion
On Wed, 11 Jul 2007 13:27:48 +0200 Fabio Strozzi [EMAIL PROTECTED] babbled: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, every time I call emotion_object_audio_volume_get(emotion) just after - or close in time to - emotion_object_play_set(emotion, 0), emotion (evas? or ecore?) blocks unexpectedly. The attached file reproduces this behaviour (for me, at least). The first argument must be a movie file. Pressing space toggles playback, pressing v calls emotion_object_audio_volume_get. If you press b, it will call emotion_object_play_set(emotion,0) and then emotion_object_audio_volume_get, causing the application to hang. This also happens if you rapidly press space and v in that exact sequence. I didn't investigate further because I'm quite unfamiliar with Posix threads and Emotion internals, but IMHO this sounds much like a race condition. Could someone test this? Thanks in advance well the app doesn't hang - the xine decoder seems to stop within emotion. something broke recently - crap. i don't know what it is. i need to narrow this down but emotion_test no longer works - rage doesnt work. g. fixed that - now found problem. xine deadlock it seems (within xine if you start and stop play and then query a parameter like audio volume while it is starting playing - not just opening). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Problem with edje and its way of dispatching mouse, * signals
On Wed, Jul 18, 2007 at 12:56:17AM -0300, Gustavo Sverzut Barbieri wrote: On 7/18/07, Brian Mattern [EMAIL PROTECTED] wrote: On Tue, Jul 17, 2007 at 06:15:51PM -0300, Gustavo Sverzut Barbieri wrote: Notice that edje property is no_mouse_grab, because then we can keep compatibility with existent .edj files. I don't like evas_object_mouse_grab_set() very much, it looks like mouse will be immediately grab, which is not the case. But I don't have any better word for that. snip + EAPI void evas_object_mouse_grab_set (Evas_Object *obj, Evas_Bool no_mouse_grab); + EAPI Evas_Bool evas_object_mouse_grab_get (Evas_Object *obj); Maybe evas_object_auto_grab_set(Evas_Object *obj, Evas_Bool auto_grab) ? (or _mouse_auto_grab_) it's not that better... other suggestions? can_grab_mouse? That makes even less sense. Maybe grab isn't a good choice. Really we're picking between two alternate methods of presenting mouse events. So, maybe evas_object_mouse_event_mode_set(obj, EVAS_EVENT_MODE_X) I'm at a loss atm as to what the two names should be though. (Maybe ORIGINAL and RAW... not happy with those...) Whatever we call it, the second parameter should NOT be no_*. It should be TRUE for grab the mouse, and simply default to TRUE. yes, I agree, but how about edje files? Can I rely on people updating their edje files? Remember that edje files will not be recompiled since they have not changed, users may issue make clean to get it updated. For edje files, you either need compatibility code (where the version is checked on load and the value is set properly), OR you can just make the edje option 'negative' (it doesn't have to be the same as the c api). However, with the above suggestion for an API, the 'original' mode would just be equal to 0. Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
