[E-devel] patch: pager: raise selected desktop before sending signal
Hello!
Here is a patch that raises selected desktop before sending it the
e,state,selected signal so that animation won't be hidden by adjacent
desktops.
Cheers!
Chidambar
Index: trunk/e/src/modules/pager/e_mod_main.c
===
--- trunk/e/src/modules/pager/e_mod_main.c (revision 36441)
+++ trunk/e/src/modules/pager/e_mod_main.c (working copy)
@@ -442,6 +442,7 @@
if (pd == pd2)
{
pd2-current = 1;
+ evas_object_raise(pd2-o_desk);
edje_object_signal_emit(pd2-o_desk, e,state,selected, e);
}
else
signature.asc
Description: PGP signature
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Etk_Scrolled_View broken?
Seems like etk_scrolled_view, when used with etk_scrolled_view_add_with_viewport produces some awkward results. It's even visible with etk_test's scrolled view dialog. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_pipe again
Peter Wehrfritz wrote: Peter Wehrfritz schrieb: Sebastian Dransfeld schrieb: Peter Wehrfritz wrote: Hi all, I took Vincent's last ecore_pipe approach and changed ecore_pipe_write to accept variable long data and not only a pointer. I also added the possibility to pass a data pointer to the handler callback to avoid the usage of globals. The win version does probably not work. Please read it carefully, because I'm not very familiar with pipes. Attached you'll find a little test app, too. Shouldn't you check that you actually read the number of bytes the system says is in the pipeline Right, sorry I forgot to mention, that I skipped them, because I'm not sure how I should handle these cases. Of course that doesn't mean that we have not to handle them. 1. What shall we do if the return size is smaller (but 0). If I understood it right, that can happen if the writing process writes more bytes then PIPE_BUF. Should we then retry it, to get the rest of the data. Or should we buffer the already read data and try it to get the rest when _ecore_pipe_read is called again. Buffering is simplest and easiest. Checking ecore main loop already checks for available data and calls the read function, so why duplicate this? 2. What should we do if we get an error messages? And when can this happen? If we can loose some bytes then we are out of sync with the lenght and data portions and the results would be randomly, but in any case wrong. Close the pipe on error and signal the sender. As you say, any error will make the pipe out of sync and void. The sender can then re-establish the pipe and resend. 3. In Vincent's version he called read as long as he gets pointer from the pipe, should I also loop as long as there is data in the pipe? Loop as long as there is data, but add a time limit. In ecore_con_url there is a limit on animator frametime. /* make this not more than a frametime to keep interactivity high */ if ((ecore_time_get() - start) ecore_animator_frametime_get()) I hope I covered here all possible errors. Can anyone help here? I don't need it personally, but it'd be nice to have it in ecore. Especially since it isn't that trivial like it looks on the first sight. Sebastian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] UDP client/server support
On Sun, Oct 5, 2008 at 12:27 AM, Matt Barclay [EMAIL PROTECTED] wrote: Hello, With this patch, ecore will have full UDP client/server support. Tooling UDP into the framework wasn't the easiest thing in the world because a UDP server has a single socket (i.e. file handle) that is used to handle all clients, whereas a TCP server generates a new socket for each client that encapsulates all the details of the connection. So here's how I implemented it: UDP Server (Unicast and Multicast): 1. When there is data on the socket, the callback uses recvfrom() to read the datagram and client address (struct sockaddr_in) 2. Create a new Ecore_Con_Client and save the client address (sockaddr_in) details with the data field. Leave the fd, buf, and fd_handler fields NULL. 3. Create a new Ecore_Con_Event_Client_Data and save the datagram in the data field, and the client in the client field 4. ecore_con_client_send() is updated to check for a client-server-type of ECORE_CON_REMOTE_UDP and use sendto() with client-data as the destination instead of appending the buffer to client-buf 5. relevant portions of ecore_con_client_del() and _ecore_con_event_client_data_free() are updated to ensure the client and data memory are freed The use of recvfrom() and sendto() feels a little dirty to me, but I'm not sure how else to preserve the client address so that packets can be sent back to the client. AFAIK, there isn't any way to do an accept() on a UDP socket such that a new file handle is created that encapsulates the end points of the UDP socket. Would appreciate some enlightenment on this topic if I'm wrong. ;) UDP Client support fits nicely into the framework as a new socket is created each time ecore_con_server_connect() is called. A UDP Server example program is included with the patch, and examples of multicast and UDP client support can be found in SVN: TEST/orig/ecore/ Looks good, but it was just an overview of the code, maybe someone will reply with more in-depth comments. As your complaing about recvfrom() and sendto(), I don't see any issue with that, udp requires us to do so. The best thing to do is to to make the ecore_con operate on callbacks (virtuals) and have different implementations for each system, then you just have the ifs on the entry point, where you select the connection type, there you set the function pointers and use them directly next times. One thing I noticed is that you leave trailing whitespaces on some lines, remove them before committing. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch: bug: exebuf on other zones doesn't allow mouse to work properly
Dans son message intitulé « [E-devel] Patch: bug: exebuf on other zones doesn't allow mouse to work properly » du Sun, 21 Sep 2008 11:38:42 +0200, Chidambar 'ilLogict' Zinnoury [EMAIL PROTECTED] nous a donné l'occasion de lire : Hello! Here is a patch for the bug: exebuf on other zones doesn't allow mouse to work properly (only zone/screen 0 works properly). There is no need to add zone coordinates while computing fed mouse event. Cheers! Chidambar ilLogict Zinnoury Committed. Chidambar signature.asc Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] patches: pager
Dans son message intitulé « [E-devel] patches: pager » du Thu, 25 Sep 2008 22:09:21 +0200, Chidambar 'ilLogict' Zinnoury [EMAIL PROTECTED] nous a donné l'occasion de lire : Hello! Here are two patches: - e-pager-move_signals.patch: prevents from sending dragging signals when moving mouse cursor over the same desktop - e-pager-deleted_border_drop_fix.patch: remove a segfault when a border has been closed before the drop actually happened (maybe display a notification to user?) Cheers! Chidambar 'ilLogict' Zinnoury Committed. Chidambar signature.asc Description: PGP signature - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: illogict trunk/e/src/modules/pager
Enlightenment SVN wrote:
Log:
Remove a segfault when a border has been closed before the drop actually
happened (maybe display a notification to user?)
Isn't it better if the closed border aborts the drag?
Sebastian
Author: illogict
Date: 2008-10-05 10:42:50 -0700 (Sun, 05 Oct 2008)
New Revision: 36453
Modified:
trunk/e/src/modules/pager/e_mod_main.c
Modified: trunk/e/src/modules/pager/e_mod_main.c
===
--- trunk/e/src/modules/pager/e_mod_main.c2008-10-05 17:34:41 UTC (rev
36452)
+++ trunk/e/src/modules/pager/e_mod_main.c2008-10-05 17:42:50 UTC (rev
36453)
@@ -2102,6 +2102,7 @@
else if (!strcmp(type, enlightenment/border))
{
bd = ev-data;
+ if (e_object_is_del(E_OBJECT(bd))) goto done;
e_layout_coord_virtual_to_canvas(pd-o_layout, bd-x, bd-y, wx,
wy);
e_layout_coord_virtual_to_canvas(pd-o_layout, bd-x + bd-w,
bd-y + bd-h, wx2, wy2);
dx = (wx - wx2) / 2;
@@ -2131,6 +2132,7 @@
}
}
+done:
for (l = p-desks; l p-active_drop_pd; l = l-next)
{
pd = l-data;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-svn mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-svn
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Update] Exchange library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 27 Sep 2008 20:55:28 +0200 Massimiliano Calamelli [EMAIL PROTECTED] wrote: Hi, here's a little status update for the client side of exchange, my library. A lot of things are done, others are coming. Hot changes from last mail: * the cli (exchange_cli) are powered by getopt * the library provide a doxy docs, ./gendoc in the root (standard layout, currently not the E standard) * a lot of new functions The code can be found here: http://staff.get-e.org/?p=users/mcalamelli/exchange.git;a=summary You're missing a file, I think. ;) $ NOCONFIGURE=X ./autogen.sh Running aclocal... /usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG /usr/share/aclocal/smpeg.m4:13: run info '(automake)Extending aclocal' /usr/share/aclocal/smpeg.m4:13: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Running autoheader... Running autoconf... Running libtoolize... Running automake... configure.ac:12: installing `./install-sh' configure.ac:12: installing `./missing' src/bin/Makefile.am: installing `./depcomp' configure.ac:69: required file `exchange.pc.in' not found Can you add the file or remove the setup for exchange.pc? $ sed -i '/exchange.pc/d' configure.ac $ sed -i '/exchange.pc/d' Makefile.am Thanks, - -sandalle - -- Eric Sandall | Source Mage GNU/Linux Developer [EMAIL PROTECTED] PGP: 0xA8EFDD61 | http://www.sourcemage.org/ http://eric.sandall.us/ | http://counter.li.org/ #196285 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjpO2YACgkQHXt9dKjv3WFMjwCgyQUO42DBRrsqlK8cjIvXrDwT OWQAoI+XxNXgvKKSHfr5zYpQnMW4vnkO =f9H1 -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore_pipe again
Sebastian Dransfeld schrieb:
Peter Wehrfritz wrote:
Peter Wehrfritz schrieb:
Sebastian Dransfeld schrieb:
1. What shall we do if the return size is smaller (but 0). If I
understood it right, that can happen if the writing process writes more
bytes then PIPE_BUF. Should we then retry it, to get the rest of the
data. Or should we buffer the already read data and try it to get the
rest when _ecore_pipe_read is called again.
Buffering is simplest and easiest. Checking ecore main loop already
checks for available data and calls the read function, so why duplicate
this?
Ok, done.
2. What should we do if we get an error messages? And when can this
happen? If we can loose some bytes then we are out of sync with the
lenght and data portions and the results would be randomly, but in any
case wrong.
Close the pipe on error and signal the sender. As you say, any error
will make the pipe out of sync and void. The sender can then
re-establish the pipe and resend.
I don't know how I can send a signal to the sender.
3. In Vincent's version he called read as long as he gets pointer from
the pipe, should I also loop as long as there is data in the pipe?
Loop as long as there is data, but add a time limit. In ecore_con_url
there is a limit on animator frametime.
/* make this not more than a frametime to keep interactivity high */
if ((ecore_time_get() - start) ecore_animator_frametime_get())
Ok, done
Please find the new patch append.
Peter
Index: Ecore.h
===
--- Ecore.h (Revision 36456)
+++ Ecore.h (Arbeitskopie)
@@ -123,6 +123,7 @@
typedef void Ecore_Event_Filter; /** A handle for an event filter */
typedef void Ecore_Event; /** A handle for an event */
typedef void Ecore_Animator; /** A handle for animators */
+ typedef void Ecore_Pipe; /** A handle for pipes */
typedef void Ecore_Poller; /** A handle for pollers */
#endif
typedef struct _Ecore_Event_Signal_User Ecore_Event_Signal_User; /** User signal event */
@@ -280,6 +281,10 @@
EAPI int ecore_main_fd_handler_active_get(Ecore_Fd_Handler *fd_handler, Ecore_Fd_Handler_Flags flags);
EAPI void ecore_main_fd_handler_active_set(Ecore_Fd_Handler *fd_handler, Ecore_Fd_Handler_Flags flags);
+ EAPI Ecore_Pipe *ecore_pipe_add(void (*handler) (void *buffer, unsigned int nbyte, void *data), const void *data);
+ EAPI void*ecore_pipe_del(Ecore_Pipe *p);
+ EAPI int ecore_pipe_write(Ecore_Pipe *p, const void *buffer, unsigned int nbytes);
+
EAPI double ecore_time_get(void);
EAPI Ecore_Timer *ecore_timer_add(double in, int (*func) (void *data), const void *data);
Index: ecore_pipe.c
===
--- ecore_pipe.c (Revision 0)
+++ ecore_pipe.c (Revision 0)
@@ -0,0 +1,498 @@
+/*
+ * vim:ts=8:sw=3:sts=8:noexpandtab:cino=5n-3f0^-2{2
+ */
+#include stdlib.h
+#ifdef HAVE_CONFIG_H
+# include config.h
+#endif
+#ifdef HAVE_EVIL
+# include Evil.h
+#endif
+#include ecore_private.h
+#include Ecore.h
+
+struct _Ecore_Pipe
+{
+ ECORE_MAGIC;
+ int fd_read;
+ int fd_write;
+ Ecore_Fd_Handler *fd_handler;
+ const void *data;
+ void (*handler) (void *buffer, unsigned int nbyte, void *data);
+ unsigned int len;
+ size_talready_read;
+ void *passed_data;
+};
+
+/* How of then we should retry to write to the pipe */
+#define ECORE_PIPE_WRITE_RETRY 6
+
+/*
+ * On Windows, pipe() is implemented with sockets.
+ * Contrary to Linux, Windows uses different functions
+ * for sockets and fd's: write() is for fd's and send
+ * is for sockets. So I need to put some win32 code
+ * here. I can't think of a solution where the win32
+ * code is in Evil and not here.
+ */
+
+#ifdef _WIN32
+
+# include winsock2.h
+
+# define pipe_write(fd, buffer, size) send((fd), (char *)(buffer), size, 0)
+# define pipe_read(fd, buffer, size) recv((fd), (char *)(buffer), size, 0)
+
+#else
+
+# include unistd.h
+# include fcntl.h
+# include errno.h
+
+# define pipe_write(fd, buffer, size) write((fd), buffer, size)
+# define pipe_read(fd, buffer, size) read((fd), buffer, size)
+
+#endif /* _WIN32 */
+
+
+static int _ecore_pipe_read(void *data,
+Ecore_Fd_Handler *fd_handler);
+
+/**
+ * @defgroup Ecore_Pipe_Group Pipe wrapper
+ *
+ * These functions wrap the pipe / write / read functions to
+ * easily integrate a loop that is in its own thread to the ecore
+ * main loop.
+ *
+ * The ecore_pipe_add() function creates file descriptors (sockets on
+ * Windows) and attach an handle to the ecore main loop. That handle is
+ * called when data is read in the pipe. To write data in the pipe,
+ * just call ecore_pipe_write(). When you are done, just call
+ * ecore_pipe_del().
+ *
+ * Here is an example that uses the pipe wrapper with a
Re: [E-devel] Patch: add jpeg thumbnail format to epsilon
On Sun, Sep 21, 2008 at 7:29 PM, Hendrik Siedelmann [EMAIL PROTECTED] wrote: Okay here it is, this patch adds the possibility to epsilon to create thumbnails in jpg format. The thumbnails are saved in FDO naming convention, just with ending .jpg. Would be glad if you could give me some feedback so this could eventually be included in svn. Patch works for me, but there are some things to mention: Ok, better late than sorry, it's commited to SVN. As for your questions: - default behaviour is like before, BUT epsilon_exists will also find jpg thumbs, so epsilon_thumb_file_get will return the jpg and epsilon_info_get will return nothing as the jpg contains no exif infos. - I don't know what happens in those HAVE_EPEG_H parts, only tested without epeg. EPEG was the old way to generate JPEGs in an efficient way. Then that code was integrated into Evas, then I deprecated EPEG (moved to OLD) when we changed to SVN. At the beginning, epsilon was not using Evas, but raster added that, but I never checked that it was not generating JPEGs, just PNGs because there was no option to select so. - new function epsilon_format_set which allows to set format to jpeg. It would be good to provide patch for BINDINGS/python-efl/python-epsilon. If you are able to provide so, mail it, otherwise I can do it for you. - also changed epsilon_thumbd and added function epsilon_request_add_advanced which can also set format (and in the future hopefully custom sizes). - changed epsilon_thumb_test to accept the arguments -large and -jpg to request thumbnails with these options. From my test the jpg output is at least two times as fast on my laptop and at least five times on the the freerunner. Also the resulting files are 10-20% the size of png thumbnails. yes, raster already provided such feedback to fdo guys, but they blindly rejected so... damn it. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
