Re: [E-devel] [PATCH] UDP client/server support
On Sun, Nov 2, 2008 at 11:53 PM, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote: > On Sat, 4 Oct 2008 23:27:33 -0400 "Matt Barclay" <[EMAIL PROTECTED]> babbled: > > hmm - you know what might have been cleaner... on data in get a CLIENT_ADD > event and literally add a client then instantly post data from that client in > a > CLIENT_DATA and then a CLIENT_DEL immediately after. it sounds a big heavy > BUT... it's clean. > > 1. it looks just like tcp/unix socket connections except the connection is > only > alive for 1 packet (lump of data). > 2. it solves your ability to preserve client info and all calls works just as > if it were tcp or unix socket. you know just where to send the data back to as > u have a client handle. :) > 3. it's clean > > what do you think? I like it, thanks for the feedback! I'm traveling early this week, but I will have a look on Wednesday. I'll keep an eye on the list in case someone beats me to it. Regards, Matt >> 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/ >> >> Regards, >> Matt >> > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] > > - 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=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Implementing a polygon / image map in edje
On Thu, Oct 30, 2008 at 2:14 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Matt Barclay wrote: >> >> Hello, >> >> I'm working on an app that let's the user control a chair. In the >> app, the user will click on the headrest, armrest, seatback, or >> footrest to control its position. Since these pieces of the chair are >> not rectangles, I'm planning on using some Embryo scripting to get the >> mouse coordinates on the chair, then figure out if the click is inside >> of the controllable areas and emit a signal. A much cleaner approach, >> I think, would be a part type POLY that would let edje do the heavy >> lifting and behave just like RECT. I can't be the first person to run >> into this challenge. How have you solved it in the past? How hard >> would it be to add POLY to edje? I see evas already has support for >> polygons. >> > > That sounds like a fun and interesting project. :) Yeah, mostly because this is our pilot EFL project! It's really incredible what these libraries can do and how easy it is to build a development process around graphic design, UI scripting, and application programming. I just discovered the part option "precise_is_inside". This may serve my selfish purposes very well. In my free time, I'll have a look at ways of specifying a POLY in an EDC and post a proposal to the list. BTW, what happened to the API docs? I'm getting a 404: http://docs.enlightenment.org/api/edje/html/edcref.html Regards, Matt > Now, as to poly objs in edje/edc, well it shouldn't be too dificult really > - > once you can come up with a reasonable edc format description which you can > edje_cc parse, save in eet as some list or array structure for the set of > vertices, > the rest is simple. > However, there are plans for overhauls of evas' polys (and other vector > objs) > and one that seems reasonable is to allow for the set of poly vertices to be > specified as floats, so you may want to allow that (even if current evas > would > truncate them to int coords). > You may also look into things like the svg, xaml, and such specs which have > similar object descriptions for inspiration on the edc format description > (xaml I believe has a polygon object, can't recall about svg - though they > both > have a more general 'path' obj description, and possibly someone may have > even > suggested a CSS based polygon or path obj description.. maybe someone from > Apple). > Lastly, you may want to speak with Cedric and Jorge, as they are both > interested > in this topic. > > > > > Overwhelmed? Click here for information on drug and alcohol rehabilitation. > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nCeLATRB3A0uPCqRbHSH68VGJaT2fHF3sPhYp5tZehw3yvj/ > - 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=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Implementing a polygon / image map in edje
Hello, I'm working on an app that let's the user control a chair. In the app, the user will click on the headrest, armrest, seatback, or footrest to control its position. Since these pieces of the chair are not rectangles, I'm planning on using some Embryo scripting to get the mouse coordinates on the chair, then figure out if the click is inside of the controllable areas and emit a signal. A much cleaner approach, I think, would be a part type POLY that would let edje do the heavy lifting and behave just like RECT. I can't be the first person to run into this challenge. How have you solved it in the past? How hard would it be to add POLY to edje? I see evas already has support for polygons. Regards, Matt - 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=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] preventing mouse events during state transition
Hello,
I'm working on a simple, multi-page application. There are four menu
buttons across the top of the screen, and 1-4 command buttons at the
bottom depending on which menu is active. When transitioning between
menus, I have the command buttons accelerate offscreen to the left.
The problem I'm having is if the user presses a button as it is
transitioning off screen. The press is handled as a button press, and
the button goes back to its original place on screen, instead of
accelerating offscreen and becoming invisible. Is it possible to
disable mouse events during a transition in my EDC? What's the best
approach here? Here are some snippets of what I'm doing right now:
ADJUST is a menu button at the top of the page. When selected, the
TTOL, LOUNGE, BED, and LOAD buttons transition offscreen to the left.
However, the user can still press these buttons while the
adjust_active3 program is running. For example, that press causes the
BED_active program to run, setting BED state to "active", thus moving
the button to its original position. The mouse,up,* event causes
BED_visible to run, leaving the button in its original position in the
"unpressed" state. The XXX_active programs cause a highlighted image
to replace the default image.
#define PROGRAM_BUTTON_ACTIVE_VISIBLE(targ)\
program { \
name: targ"_active";\
signal: "mouse,down,1"; \
source: targ; \
action: STATE_SET "active" 0.00;\
transition: LINEAR 0.0; \
target: targ; \
} \
program { \
name: targ"_visible"; \
signal: "mouse,up,*"; \
source: targ; \
action: STATE_SET "visible" 0.00; \
transition: LINEAR 0.0; \
target: targ; \
} \
PROGRAM_BUTTON_ACTIVE_VISIBLE("TTOL")
PROGRAM_BUTTON_ACTIVE_VISIBLE("LOUNGE")
PROGRAM_BUTTON_ACTIVE_VISIBLE("BED")
PROGRAM_BUTTON_ACTIVE_VISIBLE("LOAD")
program {
name: "adjust_active3";
signal: "mouse,down,*";
source: "ADJUST";
action: STATE_SET "offscreen_left" 0.00;
transition: ACCELERATE 0.5;
target: "TTOL";
target: "LOUNGE";
target: "BED";
target: "LOAD";
}
program {
name: "adjust_active4";
signal: "mouse,down,*";
source: "ADJUST";
action: STATE_SET "onscreen" 0.00;
transition: DECELERATE 0.5;
target: "SAVE";
target: "FORE_AFT";
after: "viewing_area_ttol_fadein";
after: "viewing_area_ttol_fadeout";
}
Thanks in advance!
Matt
-
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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] About animate
You can emit signals any time you want with:
edje_object_signal_emit(edje, "my,fancy,signal", "mysource");
For debugging, I like to register a stdin callback that let's me type
in a signal on STDIN which is then emitted in the application. Then
I can simulate events for the GUI and the application:
int main(void) {
ecore_main_fd_handler_add(STDIN_FILENO, ECORE_FD_READ, stdin_cb, NULL,
NULL, NULL);
}
int stdin_cb(void *data, Ecore_Fd_Handler *fd_handler)
{
int fd,num;
char buf[1024];
fd = ecore_main_fd_handler_fd_get(fd_handler);
num = read(fd, buf, sizeof(buf));
if(num > 1)
{
buf[num-1] = 0;
printf("Emmiting Signal `%s'\n", buf);
edje_object_signal_emit(edje, buf, "stdin");
}
return 1;
}
Hope that helps.
Regards,
Matt
On Thu, Oct 23, 2008 at 4:03 AM, flower-mei <[EMAIL PROTECTED]> wrote:
> hi all,
>
> Just forgive me for my trouble for you
> I know that the animate can be started when the signal be emited,
> but I don't know other way to emited the signal or set up the signal
> except when the mouse clicked signal
> is emitted.
>
> thanks ! :)
>
> -
> 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=100&url=/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
-
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=100&url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] UDP client/server support
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/
Regards,
Matt
Index: ecore/src/lib/ecore_con/ecore_con.c
===
--- ecore/src/lib/ecore_con/ecore_con.c (revision 36438)
+++ ecore/src/lib/ecore_con/ecore_con.c (working copy)
@@ -33,7 +33,7 @@
static int _ecore_con_svr_handler(void *data, Ecore_Fd_Handler *fd_handler);
static int _ecore_con_cl_handler(void *data, Ecore_Fd_Handler *fd_handler);
static int _ecore_con_cl_udp_handler(void *data, Ecore_Fd_Handler *fd_handler);
-static int _ecore_con_mcast_handler(void *data, Ecore_Fd_Handler *fd_handler);
+static int _ecore_con_svr_udp_handler(void *data, Ecore_Fd_Handler *fd_handler);
static int _ecore_con_svr_cl_handler(void *data, Ecore_Fd_Handler *fd_handler);
static void _ecore_con_server_flush(Ecore_Con_Server *svr);
static void _ecore_con_client_flush(Ecore_Con_Client *cl);
@@ -323,23 +323,31 @@
_ecore_con_svr_handler, svr, NULL, NULL);
if (!svr->fd_handler) goto error;
}
- else if (type == ECORE_CON_REMOTE_MCAST)
+ else if (type == ECORE_CON_REMOTE_MCAST || type == ECORE_CON_REMOTE_UDP)
{
svr->fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
if(svr->fd < 0) goto error;
- mreq.imr_multiaddr.s_addr = inet_addr(name);
- mreq.imr_interface.s_addr = htonl(INADDR_ANY);
- if (setsockopt(svr->fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq,sizeof(mreq)) != 0) goto error;
+
+ socket_addr.sin_family = AF_INET;
+ socket_addr.sin_port = htons(port);
+
+ if (type == ECORE_CON_REMOTE_MCAST)
+ {
+ socket_addr.sin_addr.s_addr = inet_addr(name);
+ mreq.imr_multiaddr.s_addr = inet_addr(name);
+ mreq.imr_interface.s_addr = htonl(INADDR_ANY);
+ if (setsockopt(svr->fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq,sizeof(mreq)) != 0) goto error;
+ }
+ else
+ socket_addr.sin_addr.s_addr = htonl(INADDR_ANY);
+
if (setsockopt(svr->fd, SOL_SOCKET, SO_REUSEADDR, &on,sizeof(on)) != 0) goto error;
if (fcntl(svr->fd, F_SETFL, O_NONBLOCK) < 0) goto error;
if (fcntl(svr->fd, F_SETFD, FD_CLOEXEC) < 0) goto error;
- socket_addr.sin_family = AF_INET;
- socket_addr.sin_port = htons(port);
- socket_addr.sin_addr.s_addr = inet_addr(name);
if (bind(svr->fd, (struct sockaddr *)&socket_addr,sizeof(struct sockaddr_in)) < 0) goto error;
svr->fd_handler =
ecore_main_fd_handler_add(svr->fd, ECORE_FD_READ,
- _ecore_con_mcast_handler, svr, NULL, NULL);
+ _ecore_con_svr_udp_handler, svr, NULL, NULL);
if (!svr->fd_handler) goto error;
}
@@ -806,16 +814,21 @@
if (size < 1) return 0;
if (cl->fd_handler)
ecore_main_fd_handler_active_set(cl->fd_handler, ECORE_FD_READ | ECORE_FD_WRITE);
- if (cl->buf)
+
+ if(cl->server && cl->server->type == ECORE_CON_REMOTE_UDP)
{
- unsigned char *newbuf;
-
- newbuf = realloc(cl->buf, cl->buf_size + size);
- if (newbuf) cl->buf = newbuf;
- else return 0;
- memcpy(cl->buf + cl->buf_size, data, size);
- cl->buf_size += size;
+ sendto(cl->server->fd, data, size, 0, (struct sockaddr *) cl->data, sizeof(struct sockaddr_in));
}
+ else if (cl->b
[E-devel] [PATCH] ecore multicast listener
Hello,
I am working on adding multicast support to ecore. This code let's
you set up a multicast listener using the call:
mcast_svr = ecore_con_server_add(ECORE_CON_REMOTE_MCAST,
"239.255.2.1", 1201, NULL);
The only thing new about the ecore_con_server_add() call is that the
"name" parameter is the multicast address. Previously, this parameter
was ignored for REMOTE_SYSTEM connections.
The multicast handler callback below emits an
ECORE_CON_EVENT_CLIENT_DATA signal for each multicast packet that is
received. If this is not desired, the _ecore_svr_cl_handler()
callback could be used instead. Handle the multicast client data as
usual by registering the callback:
ecore_event_handler_add(ECORE_CON_EVENT_CLIENT_DATA,
(Handler_Func)client_data, NULL);
I am going to work on UDP client and multicast support next.
Regards,
Matt
Index: Ecore_Con.h
===
RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore_con/Ecore_Con.h,v
retrieving revision 1.42
diff -u -r1.42 Ecore_Con.h
--- Ecore_Con.h 8 Jul 2008 04:08:52 - 1.42
+++ Ecore_Con.h 5 Sep 2008 03:42:09 -
@@ -79,6 +79,7 @@
ECORE_CON_LOCAL_SYSTEM,
ECORE_CON_LOCAL_ABSTRACT,
ECORE_CON_REMOTE_SYSTEM,
+ ECORE_CON_REMOTE_MCAST,
ECORE_CON_USE_SSL2 = (1 << 4),
ECORE_CON_USE_SSL3 = (1 << 5),
ECORE_CON_USE_TLS = (1 << 6)
Index: ecore_con.c
===
RCS file: /var/cvs/e/e17/libs/ecore/src/lib/ecore_con/ecore_con.c,v
retrieving revision 1.95
diff -u -r1.95 ecore_con.c
--- ecore_con.c 26 May 2008 05:16:33 - 1.95
+++ ecore_con.c 5 Sep 2008 03:42:09 -
@@ -31,6 +31,7 @@
static void _ecore_con_client_free(Ecore_Con_Client *cl);
static int _ecore_con_svr_handler(void *data, Ecore_Fd_Handler *fd_handler);
static int _ecore_con_cl_handler(void *data, Ecore_Fd_Handler *fd_handler);
+static int _ecore_con_mcast_handler(void *data, Ecore_Fd_Handler *fd_handler);
static int _ecore_con_svr_cl_handler(void *data, Ecore_Fd_Handler *fd_handler);
static void _ecore_con_server_flush(Ecore_Con_Server *svr);
static void _ecore_con_client_flush(Ecore_Con_Client *cl);
@@ -154,8 +155,10 @@
Ecore_Con_Type type;
struct sockaddr_in socket_addr;
struct sockaddr_un socket_unix;
+ struct ip_mreq mreq;
struct linger lin;
charbuf[4096];
+ const int on=1;
if (port < 0) return NULL;
/* local user socket: FILE: ~/.ecore/[name]/[port] */
@@ -318,6 +321,25 @@
_ecore_con_svr_handler, svr, NULL, NULL);
if (!svr->fd_handler) goto error;
}
+ else if (type == ECORE_CON_REMOTE_MCAST)
+ {
+ svr->fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
+ if(svr->fd < 0) goto error;
+ mreq.imr_multiaddr.s_addr = inet_addr(name);
+ mreq.imr_interface.s_addr = htonl(INADDR_ANY);
+ if (setsockopt(svr->fd, SOL_IP, IP_ADD_MEMBERSHIP, &mreq,
sizeof(mreq)) != 0) goto error;
+ if (setsockopt(svr->fd, SOL_SOCKET, SO_REUSEADDR, &on,
sizeof(on)) != 0) goto error;
+ if (fcntl(svr->fd, F_SETFL, O_NONBLOCK) < 0) goto error;
+ if (fcntl(svr->fd, F_SETFD, FD_CLOEXEC) < 0) goto error;
+ socket_addr.sin_family = AF_INET;
+ socket_addr.sin_port = htons(port);
+ socket_addr.sin_addr.s_addr = inet_addr(name);
+ if (bind(svr->fd, (struct sockaddr *)&socket_addr,
sizeof(struct sockaddr_in)) < 0) goto error;
+ svr->fd_handler =
+ecore_main_fd_handler_add(svr->fd, ECORE_FD_READ,
+ _ecore_con_mcast_handler, svr, NULL, NULL);
+ if (!svr->fd_handler) goto error;
+ }
#if USE_OPENSSL
if (compl_type & ECORE_CON_SSL)
@@ -1411,6 +1433,76 @@
}
static int
+_ecore_con_mcast_handler(void *data, Ecore_Fd_Handler *fd_handler)
+{
+ Ecore_Con_Client *cl;
+
+ cl = data;
+ if (cl->dead) return 1;
+ if (cl->delete_me) return 1;
+ if (ecore_main_fd_handler_active_get(fd_handler, ECORE_FD_READ))
+ {
+ unsigned char buf[65536];
+ int num;
+
+ errno = 0;
+ num = read(cl->fd, buf, 65536);
+ if (num > 0)
+{
+ if (!cl->delete_me)
+{
+ Ecore_Con_Event_Client_Data *e;
+ unsigned char *inbuf;
+
+ inbuf = malloc(num);
+ if(inbuf == NULL)
+return 1;
+ memcpy(inbuf, buf, num);
+
+ e = calloc(1, sizeof(Ecore_Con_Event_Client_Data));
+ if (e)
+{
+ cl->event_count++;
+ e->client = cl;
+ e->data = inbuf;
+ e->size = num;
+ ecore_event_add(ECORE_CON_EVENT_CLIENT_DATA, e,
+ _ecore_con_event_client_data_free,
+ NULL);
+}
+}
+
